Willsy

That 99/2 is *such* a cute design. Really neat.

Please do some YouTube videos of the 99/2. Next to nothing is known/seen of them.

Yeah, well, I knew what I meant You're right though!

Ah I see. Yes I saw a technique somewhere online where, on the isometric games (like KnightLore on the ZX Spectrum) they have two screen buffers. One is the background (walls, floors, objects etc). The other is a 1-bit deep bitmap. Where there's a 0, you don't draw the corresponding sprite pixel. Where there's a 1, you do draw it (or maybe the other way around, then you can use XOR). Thus it's quite simple to make a sprite move behind an object. As long as you have the memory of course. The screen on the spectrum is memory-mapped to the CPU, so it's quite easy to rapidly write to the screen (there were all sorts of tricks, like setting the stack to the screen area and doing lots of PUSHes in an un-rolled loop, etc). The problems are more severe I think on the TI with it's port-mapped VDP.

It all fits into 32 column text mode, with the exception of the very last level IIRC.

Hey great! Thanks for the offsets. Regarding moving willy left/right, I'm doing it the same as on the spectrum. X coordinate changes by 8 every four frames. During those four games just the graphic data in the sprite changes (or I load a different pattern code into the sprite). Maybe this will inspire me to get back to it. I'll do the guardian movement patterns and animations first. A large part of the engine is already done (in the machine code version). In the video I posted above its all running off the vdp interrupt. The main thread is a jmp $ loop!

I need a frame by frame by frame analysis of how willy jumps. How many pixels upwards in frame 0, how many in frame 1 etc. How many frames does he'hang' in the air (at the top of his jump) etc. Maybe you can help? Is exactly the same in jet set willy.

I've done all the rooms and all the graphics and the animation frames. I can't figure out the jumping!

Ah! The Forth is strong in you! I have a COINC word that does sprite coincidence checking. COINC ( tolerance sprite1 sprite2 -- flag ) It's not a pixel level coinc, it's a simple delta between the coordinates. if coordinates<tolerance then it's a hit. However, it tries to be clever. It first checks the hardware coincidence bit. If its *not* set then it doesn't bother doing the coordinates check. Before any of this happens, I let interrupts run with a LIMI 2/LIMI 0 sequence. That was tripping me up, as I was then reading VDPST which had just been cleared by the console ISR. Sometimes it worked, (depends where you are in the frame) but mostly not. Changing it to >837B fixed it. I think your COINC is much more sophisticated than mine?

Maybe I can get it from >837B... ED/AS manual page 405: As I understand it, this value is loaded by the console ISR due to the very fact that reading the VDP status byte clears it. I think this'll solve my issue.

Is it possible to read the sprite coincidence bit via CRU, and if so, can somebody post some example code? I have an issue where I'm wanting to check the coincidence bit, but the TI ISR has already read the VDP status, thereby clearing it. I might be able to find a workaround, but if not, I'll have to bitbang the hardware (assuming that I can). Sometimes posted some code that reads the VSYNC bit via CRU but I don't know where he got the info from - hence my question! I'll keep digging..

I'll get right on it!

100 CALL CLEAR 110 INPUT "HOW MANY DUMPS DID YOU TAKE?":DUMP 115 CALL CLEAR 120 PRINT DUMP 130 PRINT 140 PRINT "WOW, THAT IS ALOT OF DUMPS!" 150 END LMAO!

The Commodore 16 (anf the Plus/4) was a nice little machine, too. preferred the Plus/4 - liked the case design and the neat cursor keys!

Nice collection. Love the Commodore 128. Lovely machines. Is that an Amiga 500 or 600?

Yeah. I'm just gonna make out like I understood you perfectly and quietly drift away before anyone notices!

Just wondering what options exist for connecting an ST (any ST: STE, STFM, Mega, Falcon or TT) to a TCP/IP LAN?

Do it! They're fantastic machines. As you know, I'm all over the TI-99/4A which is a great little machine, but the ST is in a different league. I've got a 1040STE with 4MB upgrade and mono monitor. It's primarily intended as a MIDI workstation for my Roland JV-1080.

Tearing up here...

Nah. The same cart board does up to 64K IIRC. I've got probably 100 of those Guidry boards still in their shrink-wrap direct from the fabricators. I haven't decided if the next version of TF will be 32K or 64K. Probably 64K but there are some architectural constraints within TF that I need to overcome/re-write first. A consequence of nieve design decisions that go all the way back to 2009. TF is a bit like that old saying we have here in Brit-land, maybe you have it in the US too: "This old broom has been in our family for generations. It was my grandfather's father's broom. It's had 3 new handles and 4 new heads!"

Good stuff. For V1.3 you're going to need a bigger EPROM

I believe that's what us Brits call a BBC Master System. They're very nice machines. If Acorn is your thang, you might want to check out the Acorn Archimedes - the worlds first RISC Micro, with the first generation ARM CPU. Now, pretty much every mobile made today has an ARM CPU core in it of some kind, including those made by Texas Instruments.

If I was going to leave the TI behind (no plans to) I'd move to the Atari ST. Still got an itch to blast out some 68K assembly on that motha...!

I ain't done with Forth yet. TurboForth is only scratching the surface... There's more in me yet. I will convert you all, one by one