Asmusr

Here is a really nice tune that runs on our PSG. Found on: https://www.smspower.org/forums/17734-OfficialSMSPowerThemeTune Z80 HEART ON FIRE.vgm Z80 HEART ON FIRE.mp3

As a test for the new Super Character Set, you can try to import the graphics from Zaxxon: Choose Options > Super Character Set Choose Options > Enhanced Color mode - 2bpp Choose Import > Map Image and select the first attached file "Arcade - Zaxxon ... ". The result is 1829 characters, so it's good the maximum was increased from 1024 to 2048. [ I have attached the other, normalized, files in case anybody feel an urge to implement Zaxxon for the F18A. It can do the isometric scrolling just fine, but there are too many characters to show. I haven't tested if there are more than 256 on a single screen, otherwise it should be possible to load them dynamically. ]

For those who know git and Magellan it''s easy enough.

I don't understand, but you're welcome to make a fork of my code for the Geneve.

I have tested it as well as one person can do, so here is Magellan 4.0.0: https://magellan.js99er.net

It doesn't really tell, as far as I can see, how to write TI-99/4A keyboard code that's compatible with the Geneve. Is there a guide to writing compatible software?

What I mean is that changing something in a program that will change completely later might not be worthwhile. But here you are, a new version where the doors are re-spawning and you need to press fire before you restart. raycaster.dsk raycaster.rpk raycaster8.bin Edit: Oh yeah, there is also a chest hidden behind a secret door. You will never find it...

Hmm, obviously I didn't try to play several rounds myself. I guess I should fix that, even though it's only a demo.

Once a soldier is 'activated' and close enough, it will shoot at you no matter if there is a wall in its way. To fix this I would have to cast a ray from the soldier towards you, which would be fine if speed wasn't a major concern. So I think I will leave it as it is.

I must admit it's been a while since I looked at your documentation, and it all seems reasonable enough, but if someone was trying to make a micro Forth machine all I'm saying is that those are not given restrictions. All you absolutely need is room for a workspace.

The soldier is already using 95 of the 256 characters. It would never fit with all the different combinations of background. The alternative would be to draw it using single-color magnified sprites, but again we would soon run out of patterns.

For me the cool thing about this project is that it doesn't require F18A or SAMS. When the F18A MK2 is released, and if we have access to the expanded VDP RAM, and in particular if we could get a new bitmap mode with more colors, I would like to make a new raycaster for the F18A.

I'm not sure what it requires to run something on the Geneve. Is it mainly about not accessing the keyboard directly?

It is actually possible in some cases for the guards for shoot you through the walls, because there's no easy way to know if they can see you if you can't see them. But the thing you have noticed is a bug that I have fixed in the attached version. raycaster.dsk raycaster.rpk raycaster8.bin

Why would you be limited to 114 bytes? Once you're in, you should be able to disable interrupts and use the entire 256 bytes. You could save the original contents to VDP RAM if you want to restore it later.

It sounds like a plan. Would there be any need to keep the control signals or would it all be replaced by messages? @PeteE would you prefer binary data over the websocket or a base64 encoded string? Maybe you could specify a protocol that works for you?

I have turned it into a playable, one level demo. I have added a health bar, a score, and a sound player. The guards can now shoot you. You can no longer shoot the walls in general, but you need to shoot the doors to open them. I use that event to spawn new guards and chests. You complete the level by finding the multi-colored wall, and you die if you run out of health. In both cases the level simply restarts. raycaster.dsk raycaster.rpk raycaster8.bin

Do you think it would be possible to implement the interface at the message level instead of the byte level?

I have committed some code that sends "RESET" if cru bit 2 is set. I have also enabled setting the websocket URI in the UI.

Are the CRU bits only for the DSR to read, so I just need to store them?

I got as far as this [using your fork]:

Did you get anywhere with this?

I have pushed a branch to https://github.com/Rasmus-M/js99er-angular/tree/tipi I can't test it because I only use Windows. If the Python code can only run on a RPi I'm not likely to go any further with this. [Edit: I pushed a change because I think I got the addresses wrong.]

Excellent, I will try to add some emulation tonight. Where do you imagine the Python code would run from? An actual RPi is one option, of course, but that's probably asking too much of the regular JS99er user. I imagined putting it on a server, but that would require some kind of session/user identification. Is there anything in the code binding it to the RPi or Linux?

Is there any reason why they chose to split the expansion RAM into two memory regions (>2000 and >A000)? Plans for a bigger system ROM perhaps?