Asmusr

There is potential for some parallax scrolling, like in some of the later versions. It should be possible just by updating the name table.

You need to talk to @ralphb who developed the FinalGROM. He should be right here.

If your starting point was a plain console, I think having 32K RAM and a 96K RAM disk would have appealed to many people.

Well, after some thought I also agree with you 🙂. Because there is more to this demo than just the scanline detection, and everybody should have a chance to see it. But maybe there is a simple fix once we know what the issue with the F18A is. I could image that it's setting the collision flag on every VGA scanline instead of only setting it on even scanlines. Would that break the demo? I set up my F18A machine today for the first time since corona to be able to test it.

I discovered that I did actually fix this in the past, so the F18A emulation is also supporting line by line sprite collision detection. 🙂 This means that the demo is now running in js99er in the F18A emulation, but it doesn't work on real hardware. That makes it even more interesting for me to find out why. @matthew180

But if you fix it the next person who make a cool demo for the 9918A will run into the same problems with the F18A. So I still think it's up to Matthew to fix.

I think it's more up to Matthew than you to fix this. Using the F18A capabilities for a demo is fine, but not nearly as cool as making it run on the 9918A. If we went in and really pushed the F18A to the limit, a whole new dimension would be opening.

Wouldn't a real cart with a 27C010 (128 KiB) also wrap around?

Yes but it won't work even if I remove that line, because my F18A emulation is hacky and calculates one sprite collision flag for the entire screen.

Fixed, but still not working in the F18A emulation.

I don't agree. Drawing a few characters and sprites for a homebrew game is doable for a single developer. Drawing new graphics on a larger scale is still a huge task. Unless you convert existing graphics, which can still be a big task, but then you run into issues with copyright and credits.

Is it using the TI's VDP? If yes, how does that work?

It doesn't seem to work if there is a space in the directory name.

Haha, Paint Shop Pro says the image has 1063803 colors 🙃.

That looks really weird. Instead of solid colors each character appears to have two bands of different colors. I think it would be difficult to use that for anything.

Could somebody with an NTSC system try the attached and take a photo? Thank you. This is how it looks in an emulator without any rainbow effect. Each group of 3 characters is using a different combination of foreground and background colors. . ntsc-colors-8.bin

rpk files are really zip files. Try to rename one and see what's inside it. If you want to create a new rpk you need to edit the layout.xml file to match the ROM and GROM files inside the archive. For more information see https://www.ninerpedia.org/wiki/MESS_cartridge_handling#RomPacK_cartridge_images_.28RPK.29

Thanks, so does that mean it doesn't work if they are not in the carts folder? I usually generate my rpk files in the project folders they belong to.

Does OoeyGUI v4.0 work with rpk files? (It doesn't seem to work for me.)

I have 3-4 consoles, but none of them are set up at the moment up with screen, power, peripherals, etc. so I chose emulation only. I'm just a wannabe 😞.

It appears that graphics mode is working but bitmap mode is not, which indicates a bad VDP. If it was the VDP RAM it would be visible already on the start screen.

How come GCC is faster than assembly?

I used the keycard to access the elevator (on disk 2, I think), but there could still be a bug preventing you from doing it under certain circumstances.

That was to distinguish them from the other files with the same name. I don't think that should be the standard.