TheMole

Matthew, If I set the pattern table to start at 0x3000 in ECM3 mode, is there a way to make the F18A read the third bitplane from the GPU RAM portion above 0x3FFF?

It's been a looooong time since I got anything under 20... I swear, that was the last one!

I think you'd need to add a couple of extra events (Hurdles, Long jump, High jump, Javelin throw, ... would all work with basically the same scrolling engine, if you want to change it up skeet shooting and/or biathlon should be easy to do with static screens), and a competition mode that perhaps supports multiple players (not necessarily at the same time though, this is a high score type competition) and a couple of CPU contestants.

Nah, I use a different joystick, I thought the TI sticks were too stiff...

I'm very, very tempted to make a joke about agility of the wrist and the sort of training exercises that one would do to get said agility... I won't though, I don't wanna be a wanker about it... *ducks and hides*

Not on the actual system, but I'm figuring out what sprites would look like for this. I edited sprites from the Gameboy, Master System and Genesis from the original game to match the F18A's requirements: Only the Genesis version fits with the background, imho, but that is really at the edge of what we'd be able to do. Each player character would be made up of 15-16 16x16 sprites, which immediately puts us at the limit of what we have. We do have enough room for the two sprite's patterns in VRAM though, but we'd have to stream in the animations from the host system.

Yup, I know... but hey, this doesn't count as a real program, now does it? . Anyway, I'll take that into account next time.

I love these types of games . Just gave it one try via js99er.net and I got 0:23:43 (or thereabouts) using the arrow keys. I haven't tried any further, because my colleagues were already looking at me strangely .

xdt99 comes with a command-line tool called xvm99, which allows transfer of disk images to nanopeb/CF7+ devices, and it works beautifully on my Mac. I understand the command line might be off-putting to some (I love it personally), but at least there's a way to make it work without booting a windows or Linux PC.

Makes sense, but how would a program be able to restore GM1, color palette, etc... in such a scenario? It can never catch the reset, right?

Indeed it doesn't, but it also doesn't run the ISR so I'm curious how you get out of the program without power cycling?

Yup, that did the trick. I'd neglected to put a jump back to the first statement of the loop, so the GPU resumed in lalaland once triggered a second time. So, I am building a level editor for Alex Kidd's F18A port and figured I'd put together a demo of some F18A features myself. This one focuses on parallax scrolling. It uses the two tile layers, but also the "trigger on next scanline" feature of the GPU to create a fake 3rd layer (the house in the background) and an extra parallax effect on the floor. Video for those without F18A: C-code running on the GPU is extremely simple: // Define VRAM memory locations we want to read/write #define VREG25 *((volatile unsigned char*)0x6019) #define VREG27 *((volatile unsigned char*)0x601b) #define VREG50 *((volatile unsigned char*)0x6032) #define SCANLINE *((volatile unsigned char*)0x7000) #define SCROLL1 *((volatile unsigned char*)0x1801) #define SCROLL2 *((volatile unsigned char*)0x1802) int main(int argc, char *argv[]) { // Set stack pointer, not needed here but... __asm__("LI r15,>47fe"); unsigned char scroll1 = 0, scroll2 = 0; int factor = 0; // Write flag to trigger GPU every scanline to video register 50 (0x32) VREG50 |= 0x40; // loop that runs once every scanline while (1) { __asm__("IDLE"); // Check for start of image if (SCANLINE == 0) { scroll1 = SCROLL1; scroll2 = SCROLL2; // Only scroll half the amount for the top half of the background layer VREG27 = scroll2 >> 1; VREG25 = scroll1; } // Bottom half of background layer scrolls at normal speed if (SCANLINE > 96) { VREG27 = scroll2; } // Create extra paralax effect on floor if ((SCANLINE > 152) && (SCANLINE < 184)) { factor = SCANLINE - 152; factor = factor * (80 - SCROLL1); scroll1 = SCROLL1 - (factor >> 7); VREG25 = scroll1; } } return 0; } And a disk image for those that want to run it on the real thing is attached as well. f18atest.dsk

So clearly this works without involvement from the host program. I assume you're not just letting the GPU run at full speed but you're using VR50 to trigger the code at every scanline? So what's the overall framework for something like that then? I'd imagine something like this: Load VR54 and VR55 with the start address of your GPU code End your GPU code with an IDLE statement Let the host program set VR50 to trigger the GPU code every scanline (As in, set VR50 to a value ORed with 64). But where does execution take off when the next scanline is hit? After the IDLE statement, or at the original location set in VR54/55? Does the above sound about right?

Yeah, a kernel module or FUSE implementation would absolutely rock! I'd help, but I hate developing for OS X (probably because I'm crap at it, but also because in my very biased personal opinion Xcode is a bloated heap of steaming mammoth poo ).

I tried reading /dev/disk2 (my CF cart) on my Mac and even that gave a permission problem when launching the app via the UI (btw, thank you for making the Metal Look & Feel standard, the app works much better than v1.5 now that there's no compatibility issues with the native file dialogs). The error message was a bit confusing, so I didn't push on ("File not found: permission denied" or something along those lines), but reading your message it probably is just a matter of running tiimagetool as root.

Thanks for this, just started using xdt99's xvm99 tool to manage the volumes on my CF7+ from my Mac and it works flawlessly!

Yes, I was hoping the app could at one point support writing disk images directly to a CF card that is formatted for use with the CF7+/nanopeb. In the mean time I've figured out that Ralphb's implementation in xdt99 seems to work well, and that is cross-platform. It's also command-line based, so I can easily integrate it in my Makefiles, but it would still be nice to have a GUI app that read/write to an entire physical CF cards (I should not have called these images, that must have created additional confusion). I think TIImagetool also does not support reading from/writing to CF cards directly?

Thanks for this, it's a cool program. How hard would it be for you to add support for CF7+/nanopeb images to this? There's currently nothing (that I know) that supports writing these on the mac.

Dunno about soon, but it sure is on my list of things to do

I know I've asked this before, and I searched this thread for the answer, but I can't seem to find it anywhere. Anyway. Does the F18A implementation in js99er draw the image per scanline? ie, could I use js99er to test the development of raster effects? I know the scanline interrupt isn't supported (just reminded myself of that after hunting for a bug in my code over the past two hours or so ), but perhaps you do draw the screen one scanline at a time? Also, I have one tiny feature request: would it be possible to reload the .dsk image from disk whenever the system is reset? That would save me from having to reload the image every time I want test an updated version.

For those that are interested, it is perfectly possible to use gcc to create GPU binaries (at least in the few simple cases that I've tested). Suppose your GPU code resides in a source file called gpucode.c, you can use the following commands to get the pure binary that you can upload to the GPU: tms9900-gcc -std=c99 -Werror -Wall -c gpucode.c -Os -s -o gpucode.o tms9900-ld gpucode.o --section-start .text=0x1900 -o gpucode.elf tms9900-objcopy -O binary gpucode.elf gpucode.bin The resulting gpucode.bin file is a raw binary dump that can then be uploaded to VRAM at location >1900 (or whatever you defined with the --section-start parameter). For more complex stuff (such as when using global variables, or the heap), you need to objcopy some other sections as well, but you can easily work around the need for that in most cases by addressing VRAM directly instead of working with variables.

I'm not really doing anything complex on the GPU, so the GPU speed itself shouldn't be a problem. But I notice that when I run my code, the framerate of the overall emulation drops to about 30fps. Or alternatively, when I run some of the F18A demo programs, I get the same thing (the spinning bitmap and the plasma being two examples).

Do you have a link for those?

I don't think it has speed controls. But the real problem is the GPU in the F18A, which runs at 100mhz. Javascript just isn't fast enough on my config to emulate both the 100mhz GPU and the 3mhz CPU in parallel...

I might have to take you up on that, since a working beige console with decent keyboard is probably a pipe dream anyway . Is it a qwerty keyboard, or is it qwertz?