--- In intvprog@yahoogroups.com, DZ-Jay <dz@...> wrote:

>
> 3. I agree that the mouth animation looks too fast, but I couldn't seem to get
it right.  It either looked too slow (30 Hz) or way too fast (60 Hz). Recording
a MAME run onto mpeg tends to skip frames so I can't really tell what steps the
original is taking. Perhaps someone can offer suggestions.
>

60 hz and 30 hz are not your only two choices. If you store Pacman's frame
number in a variable that has an integer part and a fractional
part, you can add different fractional increments to run the animation at
different rates.

For example, you could keep the frame number in a 16 bit variable, where the top
8 bits are the frame to display, and the lower 8 bits are the fraction part.
Then adding different values to this number every 60 seconds would get you
different animation rates:

add 0x0100 to get 60 hz
add 0x0080 to get 30 hz
add 0x00c0 to get 45 hz
add 0x00d5 to get 50 hz etc.
(the number to add = ((desired rate) * 256) / 60

Of course the video will present 60 hz "snapshots" of whatever state Pacman is
in based on his own animation rate. But Pacman can animate at any rate.

Does this make any sense?

David

David,

That makes perfect sense, and is exactly what I do for speed scaling the sprite
movements.

What I was suggesting is that the speed may not be the only factor; it could be
the number of frames in the sequence.  Right now I am using three, but I'm not
confident that is what the original uses.

Thanks

--
Sent remotely from my iPod; so igmore teh typpos, and don't hold your breath for
a response.


On Nov 1, 2010, at 11:01, "catsfolly1234" <catsfolly1234@...> wrote:

>
>
>
>
> --- In intvprog@yahoogroups.com, DZ-Jay <dz@...> wrote:
>
>>
>> 3. I agree that the mouth animation looks too fast, but I couldn't seem to
get it right.  It either looked too slow (30 Hz) or way too fast (60 Hz).
Recording a MAME run onto mpeg tends to skip frames so I can't really tell what
steps the original is taking. Perhaps someone can offer suggestions.
>>
>
> 60 hz and 30 hz are not your only two choices. If you store Pacman's frame
number in a variable that has an integer part and a fractional
> part, you can add different fractional increments to run the animation at
different rates.
>
> For example, you could keep the frame number in a 16 bit variable, where the
top 8 bits are the frame to display, and the lower 8 bits are the fraction part.
Then adding different values to this number every 60 seconds would get you
different animation rates:
>
> add 0x0100 to get 60 hz
> add 0x0080 to get 30 hz
> add 0x00c0 to get 45 hz
> add 0x00d5 to get 50 hz etc.
> (the number to add = ((desired rate) * 256) / 60
>
> Of course the video will present 60 hz "snapshots" of whatever state Pacman is
in based on his own animation rate. But Pacman can animate at any rate.
>
> Does this make any sense?
>
> David
>
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Hello:
	 I just got back and after a quick scan through my code, I discovered why the
MOB speeds were off: as expected, I screwed up the code that loads up the table
from ROM.  What you were seeing was Pac-Man running at the speeds defined for
other entities and events, such as Ghosts tunnel traversal or frightened mode.

	 I fixed the code and verified that the speeds were being loaded correctly on
each level.  I also fixed the end frame of Pac-Man's animation when finishing
the level to have a closed mouth (as per the original).

	 And while I was at it, I also tuned the timing of the maze blinking at the end
of the level to coincide better with the arcade version.  Empirical tests
suggest that the colors alternate at slightly more than 2 Hz, or about every 25
frames; ending in the screen going blank for half this period (~12 frames).  The
blank screen especially makes the transition smoother, and gives it a nice
"Pac-Man"-ish feel.

	 Please test this version and let me know if you have any further suggestions or
comments.  I'll be working on tuning the mouth animation next, as suggested by
some of you.

	 Thanks for all the feedback!

	 dZ.

P.S. For the curious, below is the speed table I'm using, which is based on "The
Pac-Man Dossier" file by Jamey Pittman.  (Note that 100% speed is equal to 1 Hz
or about 60 frames per second.)

LEVEL 1: 80% speed (~48 Hz.)
LEVEL 2-4: 90%
LEVEL 5-20: 100%
LEVEL 21+: 90%

This demo is remarkable!  It is really starting to get a real "pacman feel".

The demo has a weird quirk; level 5 stops after the READY! and you can't do
anything more with the demo.  Since that's one of the borders of behavior in
your table, I thought it might be illuminating another bug for you.

Thanks,
Rick Reynolds
--
"Never work for a sawmill that's so behind that they don't have time to sharpen
the blades." -- Will Hayes, Software Engineering Institute



On Nov 1, 2010, at 5:02 PM, DZ-Jay wrote:

> [Attachment(s) from DZ-Jay included below]
> Hello:
> I just got back and after a quick scan through my code, I discovered why the
MOB speeds were off: as expected, I screwed up the code that loads up the table
from ROM. What you were seeing was Pac-Man running at the speeds defined for
other entities and events, such as Ghosts tunnel traversal or frightened mode.
>
> I fixed the code and verified that the speeds were being loaded correctly on
each level. I also fixed the end frame of Pac-Man's animation when finishing the
level to have a closed mouth (as per the original).
>
> And while I was at it, I also tuned the timing of the maze blinking at the end
of the level to coincide better with the arcade version. Empirical tests suggest
that the colors alternate at slightly more than 2 Hz, or about every 25 frames;
ending in the screen going blank for half this period (~12 frames). The blank
screen especially makes the transition smoother, and gives it a nice
"Pac-Man"-ish feel.
>
> Please test this version and let me know if you have any further suggestions
or comments. I'll be working on tuning the mouth animation next, as suggested by
some of you.
>
> Thanks for all the feedback!
>
> dZ.
>
> P.S. For the curious, below is the speed table I'm using, which is based on
"The Pac-Man Dossier" file by Jamey Pittman. (Note that 100% speed is equal to 1
Hz or about 60 frames per second.)
>
> LEVEL 1: 80% speed (~48 Hz.)
> LEVEL 2-4: 90%
> LEVEL 5-20: 100%
> LEVEL 21+: 90%
>
>

--- In intvprog@yahoogroups.com, DZ-Jay <dz@...> wrote:
>
> Hello:
>  I just got back and after a quick scan through my code, I discovered why the
MOB speeds were off: as expected, I screwed up the code that loads up the table
from ROM.  What you were seeing was Pac-Man running at the speeds defined for
other entities and events, such as Ghosts tunnel traversal or frightened mode.
>
>  I fixed the code and verified that the speeds were being loaded correctly on
each level.  I also fixed the end frame of Pac-Man's animation when finishing
the level to have a closed mouth (as per the original).
>
>  And while I was at it, I also tuned the timing of the maze blinking at the
end of the level to coincide better with the arcade version.  Empirical tests
suggest that the colors alternate at slightly more than 2 Hz, or about every 25
frames; ending in the screen going blank for half this period (~12 frames).  The
blank screen especially makes the transition smoother, and gives it a nice
"Pac-Man"-ish feel.
>
>  Please test this version and let me know if you have any further suggestions
or comments.  I'll be working on tuning the mouth animation next, as suggested
by some of you.
>
>  Thanks for all the feedback!
>
>  dZ.
>
> P.S. For the curious, below is the speed table I'm using, which is based on
"The Pac-Man Dossier" file by Jamey Pittman.  (Note that 100% speed is equal to
1 Hz or about 60 frames per second.)
>
> LEVEL 1: 80% speed (~48 Hz.)
> LEVEL 2-4: 90%
> LEVEL 5-20: 100%
> LEVEL 21+: 90%
>
This looks remarkable!  Incredible job.
I do have one question - the power pellets (bigger pellets), seem to blink about
twice a second, but every now and then they stutter a bit (hold an extra frame
or go one frame faster than before).  Is that due to the change in speed for
Pac-man, or something else?  Or am I imagining things?

--- In intvprog@yahoogroups.com, "sinclaj1" <sinclaj1@...> wrote:
>
>
>
> --- In intvprog@yahoogroups.com, Joe Zbiciak <intvnut@> wrote:
> >
> > dZ, Phil,
> >
> > It turns out the "odd/even packed" format isn't possible on Mattel's carts,
since they used 10-bit wide ROMs.  :-)  So, everything is just encoded with ROM
location per row of graphics.
> >
> > Anyway, if you pop open a hex editor on the "BIN" version of the game,
you'll find a number of graphic pictures start around offset 0x4ABC.  Dunno if
the basketball is in that particular set of graphics, but it's worth looking.
> >
> > In a hex editor (or in a hex dump such as what you get from SDK-1600's
"tohex" utility), you'll see graphics data interleaved with 00s.  For example:
> >
> >  00 00 00 06 00 06 00 0C   00 0C 00 0C 00 00 00 0C  # ................
00004AB0
> >  00 0C 00 0C 00 3C 00 28   00 28 00 08 00 0C 00 00  # .....<.(.(......
00004AC0
> >  00 00 00 0C 00 0C 00 38   00 38 00 3C 00 00 00 1C  # .......8.8.<....
00004AD0
> >  00 3E 00 22 00 2E 00 28   00 20 00 20 00 10 00 00  # .>."...(. . ....
00004AE0
> >  00 00 00 06 00 06 00 1C   00 3C 00 2F 00 20 00 1C  # .........<./. ..
00004AF0
> >
> > The "odd" bytes are the graphics data, and the "even" bytes need to remain
as zeros.
> >
> > Enjoy!
> >
> > --Joe
> >
> >  --
> > We sell Spatulas, and that's all!
> > http://spatula-city.org/~im14u2c/
> > http://sdk-1600.spatula-city.org/
> > http://spacepatrol.info/
> >
> >
> >
> >
> > ________________________________
> > From: DZ-Jay <dz@>
> > To: intvprog@yahoogroups.com
> > Sent: Fri, June 25, 2010 8:46:09 AM
> > Subject: Re: [intvprog] Slam Dunk - How to change stats, add a few small
things?
> >
> >
> > Phil Lewis wrote:
> > >> And, little things like making the ball a solid
> > >> object instead of a loop.
> >
> > This one strikes me as pretty simple.  Armed with a Hex-Editor, all you
> > need to do is to look for the particular pattern for the ball sprite and
> > replace it.  This may be a bit tricky, depending on how the image data
> > is encoded, but still not very hard.  It also takes a bit of programming
> > knowledge to understand how the data could be stored.
> >
> > For example, let's suppose the sprite you are looking for is like this,
> > where the '.' represents a blank pixel and the '#' represents a colored
> > pixel:
> >
> > ........
> > ...##...
> > ..#..#..
> > .#....#.
> > .#....#.
> > ..#..#..
> > ...##...
> > ........
> >
> > You must take each of those pixel rows and turn them into the
> > appropriate binary word, where '0' and '1' represent the pixels' state,
> > respectively as above:
> >
> > 00000000
> > 00011000
> > 00100100
> > 01000010
> > 01000010
> > 00100100
> > 00011000
> > 00000000
> >
> > Each word represents a byte of data.  We must then turn this into
> > Hexadecimal so that we may use the Hex-Editor to find it:
> >
> > 00000000    ; Hex: $00
> > 00011000    ; Hex: $18
> > 00100100    ; Hex: $24
> > 01000010    ; Hex: $42
> > 01000010    ; Hex: $42
> > 00100100    ; Hex: $24
> > 00011000    ; Hex: $18
> > 00000000    ; Hex: $00
> >
> > Note that since the ROMS store data in 10- or 16-bit wide words, each
> > byte would take a full word to store.
> >
> > There are basically three ways the data could be stored in ROM (there
> > may be more, of course, but we're going to assume that programmers back
> > then had better things to do than getting too fancy with their storage):
> >
> > 1. Straight, top to bottom stream, where each byte is stored in its own
> > word, following one another:
> > Row 1:
> > [<-- 16 bits -->]
> > 00000000 00000000 ; $00
> > [ n/a  ] [ row1 ]
> >
> > Row 2:
> > 00000000 00011000 ; $18
> > [ n/a  ] [ row2 ]
> >
> > PATTERN: $0000 $0018 $0024 $0042 $0042 $0024 $0018 $0000
> >
> > 2. Compacted where each word contains a pair of bytes, with the odd row
> > taking up the higher byte, and the even row the lower byte:
> >
> > Rows 1, 2:
> > [<-- 16 bits -->]
> > 00000000 00011000 ; $00 $18
> > [  odd ] [ even ]
> >
> > PATTERN: $00 $18 $24 $42 $42 $24 $18 $00
> >
> > 3. Compacted for faster retrieval, where each word contains a pair of
> > bytes, but the odd and even rows are reversed:
> >
> > Rows 2, 1:
> > [<-- 16 bits -->]
> > 00011000 00000000 ; $18 $00
> > [ even ] [  odd ]
> >
> > PATTERN: $18 $00 $42 $24 $24 $42 $00 $18
> >
> > Once you find the block where the sprite data is stored, all you need to
> > do is replace it with your own data.  For your example of a solid disc,
> > you could use the following sprite:
> >
> > ........
> > ...##...
> > ..####..
> > .######.
> > .######.
> > ..####..
> > ...##...
> > ........
> >
> > This turns into the following binary pattern:
> >
> > 00000000    ; Hex: $00
> > 00011000    ; Hex: $18
> > 00111100    ; Hex: $3C
> > 01111110    ; Hex: $7E
> > 01111110    ; Hex: $7E
> > 00111100    ; Hex: $3C
> > 00011000    ; Hex: $18
> > 00000000    ; Hex: $00
> >
> > And then it's a matter of storing the Hexadecimal values in the same
> > order as you found the original ones, i.e. either straight top to
> > bottom, compacted, or compacted in reverse.
> >
> > I hope this helps.
> >
> > Cheers!
> > dZ.
> >
>
> Thanks for the help guys.  Went to that section and pretty much pasted
everything in binary from 0x3500 - 0x5400 into excel and did some fancy stuff to
it to make it look like graphics.  Was easy to find the ball after that.  Made
the changes and it looks so much better!
>
> Now to make the baskets look more realistic, instead of like they're 5 feet in
diameter.  =)  Never understood that.
>

FYI - I showed a rough prototype of my changes (my Dad's name in the game)
earlier this year and he thought it was great.  (Played on an emulator).

I've since made changes to every player, including stats and prices, and through
the magic of the Cuttle Cart 3, I get to surprise my father with something he
never thought he'd ever see in his lifetime...his name (and his family and
friends) in a game in an Intellivision cartridge that he can share with his
friends.

On Nov 01, 2010, at 17:24, sinclaj1 wrote:

> This looks remarkable!  Incredible job.
> I do have one question - the power pellets (bigger pellets), seem to blink
about twice a second, but every now and then they stutter a bit (hold an extra
frame or go one frame faster than before).  Is that due to the change in speed
for Pac-man, or something else?  Or am I imagining things?

Hum... They should blink at about 3 Hz, being on slightly longer than off.  I
haven't notice the stutter at all.  Are you trying in the emulator or in CC3?

	 dZ.

On Nov 01, 2010, at 17:17, Rick Reynolds wrote:

> The demo has a weird quirk; level 5 stops after the READY! and you can't do
anything more with the demo.  Since that's one of the borders of behavior in
your table, I thought it might be illuminating another bug for you.

DOH! Just saw that, you're right.  I'll debug and find out.  Thanks!

	 dZ.

On Nov 01, 2010, at 17:29, DZ-Jay wrote:

>
> On Nov 01, 2010, at 17:17, Rick Reynolds wrote:
>
>> The demo has a weird quirk; level 5 stops after the READY! and you can't do
anything more with the demo.  Since that's one of the borders of behavior in
your table, I thought it might be illuminating another bug for you.
>
> DOH! Just saw that, you're right.  I'll debug and find out.  Thanks!

Rick,
	 Try now.  The problem was that I was loading the speeds into 8-bit Scratch RAM,
when they are 16-bit fractional values (8.8); thus when the 5th level came
around for 100% speed (1.0 Hex %), the fractional value was the only thing
retained.  It works now.


sinclaj1,
	 I really cannot reproduce what you described, but I'm testing on jzIntv not in
the real console.  Can anybody else experience the same thing?

	 Thanks all!
	 dZ.

I played with the latest one for several levels - didn't find any flaws!  Again,
impressive work.

Thanks,
Rick Reynolds
--
"There are many shades of 12." -- Glenn Beck


On Nov 1, 2010, at 5:54 PM, DZ-Jay wrote:

> [Attachment(s) from DZ-Jay included below]
>
> On Nov 01, 2010, at 17:29, DZ-Jay wrote:
>
> >
> > On Nov 01, 2010, at 17:17, Rick Reynolds wrote:
> >
> >> The demo has a weird quirk; level 5 stops after the READY! and you can't do
anything more with the demo. Since that's one of the borders of behavior in your
table, I thought it might be illuminating another bug for you.
> >
> > DOH! Just saw that, you're right. I'll debug and find out. Thanks!
>
> Rick,
> Try now. The problem was that I was loading the speeds into 8-bit Scratch RAM,
when they are 16-bit fractional values (8.8); thus when the 5th level came
around for 100% speed (1.0 Hex %), the fractional value was the only thing
retained. It works now.
>
> sinclaj1,
> I really cannot reproduce what you described, but I'm testing on jzIntv not in
the real console. Can anybody else experience the same thing?
>
> Thanks all!
> dZ.
>
>

On Nov 02, 2010, at 04:37, Joe Zbiciak wrote:

> I thought for a moment that the glitch might be due to uninterruptible
> instructions.  I went and patched the MVO/JSRD sequence at $58DF to make it
more
> interruptible, and that didn't help.

Strange.  Could you describe the glitch a bit more, I'm not sure I understand
what it looks like.  Is it that the background tiles are replaces by ROM fonts
or garbage?

By the way, $58DF is a critical section that updates Pac-Man's sprite record in
RAM and its Shadow STIC registers, all part of the trailing end of the
MOVE_PACMAN() routine.  Attached is that chunk of code.

The entire Shadow STIC is being block-copied into the STIC on every frame of the
level engine, but I only write to the MOB #0 registers of the Shadow at the
moment.

It could be a stack overflow.  I've had such quirky things happen before, and it
was due to the the stack overwriting Scratch RAM, but usually my repeating tasks
are the ones affected, for that is where the TASK manager data structures
reside.

Is there anything I can do or provide to you that will help debug this?  I
haven't tried my CC3 yet because I don't have an SD card reader and also because
my computer and Intellivision are in completely separate rooms.

	 dZ.

On Nov 02, 2010, at 07:19, DZ-Jay wrote:
>
> By the way, $58DF is a critical section that updates Pac-Man's sprite record
in RAM and its Shadow STIC registers, all part of the trailing end of the
MOVE_PACMAN() routine.  Attached is that chunk of code.

Attached now, for sure.  Sorry.

	 dZ.

On Nov 02, 2010, at 04:37, Joe Zbiciak wrote:

> If I hold down the controller while Pac-Man is moving, I get some sort of
random
> glitching along the left-edge of the screen.  It only happens while the
> controller is pressed.  If I tap to move, I only get a momentary glitch when
> tapping.  If I hold it, the glitch remains every frame.

Joe,
	 It sounds suspiciously like the glitches I was experiencing when you enabled
"dirty-rectangles" in jzIntv and I had it set to use double-buffering also.  I
wonder if it is a bug in my code that is masked by the dirty-rectangles
rendering in jzIntv.

	 dZ.

Hey there,

The feel of this demo is amazing. It seems to get better every step of the way.
I used to like the INTV/Atarisoft version a lot. That version is getting worse
and worse to me, as yours continues blows it out of the water.

Also, Im back from vacation and can continue on with my intelliwiki mirror:
http://wiki.intellivision.dreamhosters.com/wiki/Main_Page


Mike

On Nov 02, 2010, at 12:05, Joe Zbiciak wrote:

> You don't re-draw the BACKTAB tiles for the maze during the level do you?  I
> don't think you do.

No, I only draw the maze during level initialization; it's very expensive as it
is.

>   That, and some careful eyeballing are what suggest to me it
> is likely a MOB showing up over there.  But why?  I don't know.

I just discovered that, although only Pac-Man is being used, all MOBs have the
"visible" bit on, and some of the registers were hard-coded with some colors; a
remnant of my old sprite tests from months ago I guess.

Perhaps that was it.  I'm enclosing a newer version in which the MOB registers
are all zero-ed, and only Pac-Man MOB is set to something.  I also show or hide
the Pac-Man MOB when needed, instead of hard-coding it to visible all along.

Please test it and let me know.

One more thing that's changed in this version is the introduction delay:  On the
very first level, the maze is drawn and the "Ready!" message is displayed for
about 2 seconds while the jingle starts playing, and then it enters the "Intro"
state where Pac-Man and the Ghosts are shown for two more seconds prior to
beginning the level.  I played it side-by-side against MAME and the timing seems
almost perfect.  All but the Jingle and the Ghosts is there! :)

	 dZ.

Impressive stuff, Joe!

	 dZ.

On Nov 01, 2010, at 14:08, Joe Zbiciak wrote:

> All,
>
> Just a minor bugfix.  The version posted earlier could end up losing some
pixel
> updates if multiple "lines" wrote into the same blank card in the same frame.
> The fix is a one-liner:  Write the allocated GRAM card info to BTAB
immediately,
> but leave the color set to "black" so it doesn't display yet.
>
> Also, credit where credit is due:  I got the idea for this sort of LRU-based
> dynamic update from some of the dynamic GRAM allocation work Arnauld
Chevallier
> has done in the past, for example in IntyOS.  He deserves a bit of the credit
> for this sort of approach.  I just applied my own twist on it here.  :-)
>
> --Joe
>
> --
> We sell Spatulas, and that's all!
> http://spatula-city.org/~im14u2c/
> http://sdk-1600.spatula-city.org/
> http://spacepatrol.info/
>
>
>
>
> ________________________________
> From: Joe Zbiciak <intvnut@...>
> To: INTVPROG <intvprog@yahoogroups.com>
> Sent: Mon, November 1, 2010 12:16:09 PM
> Subject: [intvprog] Tech demo:  Dynamically allocated bitmap sketch buffer [4
> Attachments]
>
>
> [Attachment(s) from Joe Zbiciak included below]
> Someone on AtariAge asked if a Missile Command type of game could be done for
> the Intellivision.  Now, I happen to think that Imagic's Atlantis captures a
> similar sort of gameplay rather beautifully (both in how it looks and how it
> maps to the Intellivision's controls), but that's beside the point.  The main
> technical question for me was whether the Intellivision could do the bitmapped
> lines such as what the original game did acceptably.
>
> I whipped up a quick tech demo last night while on a long plane flight (and
> spent this morning debugging it).  This demo is completely un-optimized.  I
just
> threw it together as quickly as possible to see if I could make the basic
> concept work.  The idea is this:
>
>  * Use a pool of GRAM cards to provide a simple "sketch  buffer"
>  * Dynamically associate GRAM cards with BACKTAB locations
>  * When plotting a pixel, see if the corresponding BACKTAB location has a GRAM
> card associated with it.
>
>
>  * If so, update the GRAM card to set the pixel.
>  * If not, take the least recently updated GRAM card, blank it, and
reassociate
> it with the new BACKTAB location and then do the update
> In the attached demo, I use a pool of 48 GRAM cards (configurable), and draw 8
> different "incoming missiles" (also configurable) at random approach
> velocities.  When a missile hits the bottom or goes off the side, I
reinitialize
> it at the top of the screen with a new random velocity.
>
> It ends up working out pretty well.  While I don't intend to turn this into
> Missile Command, I think it does demonstrate how effective dynamic GRAM
> remapping can be at providing flexible "bitmap-like" displays for a game like
> this.  If someone wants  to take this code and use it for something, go for
it.
> I'll warn you, though, it isn't optimized at all.  :-)
>
> Enjoy!
>
> --Joe
>
> --
> We sell Spatulas, and that's all!
> http://spatula-city.org/%7Eim14u2c/
> http://sdk-1600.spatula-city.org/
> http://spacepatrol.info/
>

On Nov 02, 2010, at 12:34, Joe Zbiciak wrote:

> There does seem to be a different glitch--the screen jumps occasionally now.
> That is due to non-interruptible instructions, and is probably due to that
> critical section you posted before.  I'm not sure why I didn't see the jumping
> before, though.

There's various critical sections in that MOVE_PACMAN() procedure... I'm curious
as to why you think is that one particularly?  And does your patch solve the
glitch this time?

	 dZ.

On Nov 02, 2010, at 12:34, Joe Zbiciak wrote:

> dZ,
>
> That did seem to eliminate the glitch, though I'm not 100% certain why, since
I
> never saw the X position move from '0' in the emulator, so theoretically those
> MOBs shouldn't have been displayed anyway, regardless of VISB=1.
>
> There does seem to be a different glitch--the screen jumps occasionally now.
> That is due to non-interruptible instructions, and is probably due to that
> critical section you posted before.  I'm not sure why I didn't see the jumping
> before, though.
>

Joe,
	 Analysing the CPU history (from the emulator) shows that the only section where
BUSQ is being delayed for more than one instruction is from $56BB to $56C2,
which is switch case:

56b7 56c3 	 @@switch:       DECLE   @@case_0
56b8 56c1 		                DECLE   @@case_1
56b9 56be 		                DECLE   @@case_2
56ba 56bb 		                DECLE   @@case_3
56bb 0066 	 @@case_3:       SLR     R2,     2
56bc 0066 		                SLR     R2,     2
56be 0066 	 @@case_2:       SLR     R2,     2
56bf 0066 		                SLR     R2,     2
56c1 0066 	 @@case_1:       SLR     R2,     2
56c2 0066 		                SLR     R2,     2
56c3 03ba 000f 	 @@case_0:       ANDI    #%1111, R2

	 Other than that, I do not see BUSQ being delayed, except for a single
instruction here and there.  I have added NOPs between the cases to relieve
this.  Can you try now, please?

	 Thanks,
	 dZ.

On Nov 02, 2010, at 13:02, Joe Zbiciak wrote:

> Ok, I just tried this version without any other patches, and it seems to
> eliminate the remaining "jump glitch."  Bravo!  I guess that other section I
> worried about wasn't a problem.

Yay!

I'm thinking of patching the other block if anyway.  My intention was to update
the RAM position variables and the STIC shadow in one go to ensure their mutual
consistency; but I guess the risk of disparity is minimal if I break up the
critical section:  since an IRQ at that point will just add the MOVE_PACMAN()
task to the queue and not call it directly, the function won't be re-entered, so
there is little chance (if any) that the position will be updated before the
call to __UPDATE_PAC_POS ($599D).


> The section you show below shouldn't delay BUSAK by more than 56 cycles (6
SLRs
> followed by the ADDI).  I'm starting to suspect that arithmetic instructions
> (ie. MVI@, ADD@) that update R7 might be non-interruptible.  Time for an
> exploratory test, I guess.

I'm curious, how do you expect to test for this?  Is it going old-school, with
the oscilloscope and a voltammeter?

	 dZ.