NeoGeo

[tcdev]

It's time I tackled something a little more complex - so I've decided to do some preliminary work on the NeoGeo. :eek:

I'm not quite sure I've got a platform capable of running a full game, but I've started on the DE1/DE2 platforms anyway.

The NeoGeo actually isn't very difficult - it's a simple tilemap layer and a whole bunch of sprites - *LOTS* of *BIG* sprites! There's a lot of devil in the detail of course - raster effects, zooming, interrupts, Z80 communications etc - but the most significant problem is the sheer size of the ROMS required. The smallest game weighs in at 22MiB, the largest around 1Gib I believe. :(

Correction: the smallest is only 22Mib (bits)! That's only 2.75MiB!

I thought the best way forward is to start a *software* NeoGeo emulator from scratch and build it up gradually in parallel with the FPGA implementation. To this end, I've started with Neill Corbett's Starscream 68k core (nice!) and the Allegro graphics library. With a few patches (3) to the system BIOS I can now advance through the hardware test screens. Only the fixed layer (tilemap) is implemented.

As for the FPGA, it displays the contents of the VRAM on the VGA output. No palette has been implemented yet - in fact, it's monochrome only atm.

Stay tuned! :cool:

[tcdev]

I've implemented the first 16 palettes, accessible by the fixed layer. :cool:

I'm in the process of adding Tobias' TG68 68k soft core and an SDRAM controller. I can run a small boot ROM from internal RAM, but it has problems... still working out how to interface to the core... :(

[tcdev]

I've instantiated the 68k core and a small (2KiW) boot ROM in on-chip memory. The idea is that this boot rom will seed the SDRAM from another source - initially the flash but ultimately SD card, for example, much like Minimig.

I've got some test code running in the ROM which sets a few LEDs and tests a single location on the external SRAM (where the cpu working RAM and the battery-backed SRAM will be stored). So far so good. :cool:

Right now I'm attempting to get the boot rom code to write to the fixed layer on the video display. Not only will it confirm that the system bios will be able to write to the screen, but I'll also have some debug output.

UPDATE: It works!!!

Once I get that going, the next step is to hook up the SDRAM controller to the 68k core and do some read/write tests. If all goes well I can then seed the SDRAM with the system BIOS from flash and boot the NeoGeo BIOS!

[MiniMorph]

You really have been busy.

I am pleased you are getting on to the platforms that will benefit from the SD Card.

Getting a 68000 core running is great.

I would like to try some of your efforts on my DE1 if that's OK. I cannot see anywhere round here where I can get the HDL or built cores from can you point me in the right direction.

What state was the BBC Micro core when you left it ?

And the TRS80 ?

On a different front did you notice MikeJ's (fpgaarcade) announcement that he was changing his platform to remove the real 68k of his main board. That was the most puzzling inclusion in his project so his board will be much better without the cost and waste of pins of a real 68k wired to the FPGA.

All the best.

I am determined I will get in to this FPGA stuff at some point.

Sorry for the rambling message.

Keep up the good work.

[tcdev]

I would like to try some of your efforts on my DE1 if that's OK. I cannot see anywhere round here where I can get the HDL or built cores from can you point me in the right direction.

See this thread here...
http://pacedev.net/forums/showthread.php?t=8

What state was the BBC Micro core when you left it ?

The BBC was running, BASIC prompt and graphics and everything except Teletext font mode. There was no secondary storage support for it.

I'll need to update it to the latest architectural changes. Shall do that ASAP and let you know!

And the TRS80 ?

Support for Model III Newdos/80 disk images in flash and/or sram. Write support for sram disk images.

On a different front did you notice MikeJ's (fpgaarcade) announcement that he was changing his platform to remove the real 68k of his main board. That was the most puzzling inclusion in his project so his board will be much better without the cost and waste of pins of a real 68k wired to the FPGA.


Yes, looks like he tried to fit too much on the board, which I have also been guilty of in the past, and also why my PACE-JAMMA PCB is still waiting to be finished! :(

Thanks for the kind words and your "ramblings" are always welcome here! :)

[tcdev]

Some good news - it looks like the stock DE1 will be capable of booting the NeoGeo BIOS without using SDRAM! :cool:

Boot ROM and boot DATASTORE support has now been added to the software emulator. I can now boot from my boot ROM, have it copy the BIOS from DATASTORE into the system bios memory area, and print a banner after calling a BIOS subroutine!

So tonight the idea was to implement the same in hardware. I almost got there... I can boot from my boot ROM and have it copy the BIOS data from DATASTORE (flash) into the system bios area (SRAM), and print a banner - if I don't call the bios subroutine. Turns out that it's only copying every 2nd byte into SRAM. I'm sure it's a trivial bug but at 3am it's time to go to bed. :(

After copying the system bios, a 'magic' register maps out the boot rom and data store and enables the flash on the tilemap data bus - a regular NeoGeo memory map.

In the process I had to add a 320x480 video mode - clocked at 12.5MHz - because the fixed layer tile data (128kB) is read from the 70ns flash. Rather than use a 12.5MHz clock, I'm using the clock-enable on the video controller which hasn't really been tested until now. Verdict - works 99%.

That aside, once I sort out the issue with the bios copy, I should be able to have the boot rom code reset the 68k and the real neogeo bios should then boot into self-test mode! :cool: I've got some more logic to implement before it gets to the on-screen menu, but it's all been done in my software emulator!

I'll post some eye candy when I get that far...

[tcdev]

The "P.A.C.E. NeoGeo Boot ROM" copies the system bios from flash into SRAM, patches a few self-test routines, swaps the sfix (tile) layer graphics data in, waits for a key, and then reboots the NeoGeo hardware.

I've got the BIOS booting up to the hardware test screens now. VBLANK interrupts are implemented and there's enough functionality in the uPD4990A RTC chip to provide time and interval pulses to pass the "calendar test" (which really only counts vblank interrupts in a 1s period).

I can flip through the self-test screens and all the inputs - dipswitches and user controls - appear to work.

I can't read or set the date/time atm, although that functionality has been implemented and simulated in the uPD9440A. Next chance I get it'll be working on getting that going, then maybe seeing what happens if I try to get "Joy Joy Kid" to boot. :cool:

Limitations atm include:
* palette ram limited to 1st 16 palettes accessible by sfix layer - only to leave room for SignalTap in the DE1's 2C20
* video ram limited to sfix "tilemap" area
* no sprites implemented
* no horizontal display interrupt

[tcdev]

...but can't set it yet... :confused:

[tcdev]

As above, can set and read the time. Exciting - NOT!

Now to look at what other hardware (interrupts etc) I will probably need to implement before I attempt to load a game program ROM and see what happens... :cool:

[tcdev]

After recently working with Zet, I've had the idea of using the yadmc (sdram controller) core in the NeoGeo, as opposed to my previous (unsuccessful) quick 'n' dirty hack-job attemping to use a NIOS SOPC sdram controller.

This should be much easier and more reliable to hook up given the wishbone interface to an asynchronous SDRAM back-end.

I've added the yadmc core to the project and (tentatively) hooked it up, but I now need to go back and relearn how I had everything mapped into the various memories (flash, SRAM, external SRAM, SDRAM) on the DE1 so I can check it all before I hit the big red GO button.

Something else I'd like to work on, in parallel with the Zet effort, is loading the BIOS into SDRAM from SD card.

[tcdev]

Don't you hate it when things that used to work - don't? :(

I hooked up the yadmc core but can't get the BIOS booting out of SDRAM.

So I added a switch to select SRAM/SDRAM for the BIOS, and now booting from SRAM won't work any more.

It may be because it doesn't meet timing. Or I stuffed something up. Either way, it's a PITA!

[tcdev]

I think the SDRAM controller is working now.

However, the system still won't boot from either SRAM or SDRAM. I've modified the bootloader to verify the contents of S(D)RAM after copying the BIOS - and it passes on both accounts. The BIOS 'clear sceen' function also appears to execute correctly out of both SRAM and SDRAM...

SRAM boots to the "WORK RAM TEST" screen and hangs.

SDRAM doesn't show anything on the screen after booting the NeoGeo.

I'm beginning to suspect timing problems, as the design doesn't meet timing in the 68K core...

[tcdev]

Title says it all!

Turns out that it was booting from SRAM all along - I just had the DIPSWITCH settings wrong and was using the wrong key to advance through the BIOS screens! Doh! This time I made a note in the source code!

And there wasn't a timing issue (although I have improved timing) at all. I wasn't mapping the vectors in properly as it turns out.

Next step - load up the flash with a game rom, modify the boot rom to copy to SDRAM, and then hit the big red GO button! :cool:

[tcdev]

I can see the game code running through the attract mode, and can even start a game (from freeplay setting).

Still a long way to go, don't even have the cartridge fixed-layer graphics roms loaded... and I haven't even started on the sprite implementation yet...

UPDATE: I've added the cartridge fixed-layer graphics and they appear to work OK!

[tcdev]

Finally, I squashed a few cut 'n' paste and careless bugs and Joy Joy Kid now runs entirely from SDRAM (not using SRAM). This should've taken 20 mins but instead has taken 2 days. ^&#@*^%$

Next step is to load the sprite data into SRAM. But first I need to add a bank-switch to the bootdata (flash) as it currently is limited to 2MB in 68K address space. I'd say it is trivial, but after the SDRAM debacle...:mad:

I'll jury-rig the stock PACE sprite engine and see what shows up with, say, 8 sprites working...

[tcdev]

.. but little to show for it.

I've added a bank register to the bootdata (flash). I moved the Joy Joy Kid cart ROM into bank1 and it copies to SDRAM and verifies OK.

I've decoded the Joy Joy Kid cart sprite data (after much time-wasting trying to work out the bit encoding - eventually I found the code in the MAME driver - doh!) and programmed it into bank 2 of the flash. The bootloader copies half of it into SRAM and it verifies OK.

I started looking at implementing sprites. I've added the various VRAM banks - enough for the 1st 32 sprites. The DE1 isn't going to be able to implement all sprites as it requires about 128KB of dual-port RAM. But I'm assuming Joy Joy Kid is going to make fairly heavy use of the 1st 32!?! :confused:

As for the sprite engine itself - I was going to attempt to jury-rig the stock PACE sprite engine but it's not going to "fit". So I've started looking at what I'll need to change to get something running ASAP. I'm hoping I can re-define the PACE sprite modules/interfaces in the NeoGeo project without breaking the PACE framework; that's what I've strived to permit as far as possible in my recent re-architectures so fingers crossed! :eek: