Amiga core update – Blitter issues and chipset timing

The AGA core is pretty stable now, but one issue which has been haunting me for ages is some blitter operations go wrong and leave garbage on the screen.

I’ve been working with Jim Drew, who pointed me at some source code released by DMA designs for Menace – Amiga Format issue 8 or 9 I think : AmigaFormatIssue009

This was a fairly simple sub-section of the game which showed how the parallax scroll worked. It also nicely exhibited the problem with my core. When you are debugging complex hardware, usually we use a simulator to see what’s going on. It takes several minutes to simulate one frame of video (on bigger projects it can take hours) so it really helps to get as simple a test case as possible. The testbench I use can load in SREC files from the cross assembler directly into the DRAM in the sim, so I can run exactly the same software as on the hardware.

sim

To make sure the OS doesn’t get in the way, I upload a simple bootstrap binary to 0xF80000 (where the Kick ROM would live) which jumps to 0x20000 in chip men – where I have also uploaded my test program and any resource files needed. The files are in the forum here

 

I took the Menace code, and kept chopping bits out, until I had the simplest possible case where the problem was still visible. Just blitting one tile over and over showed random corruption. I then saw in the simulator that the next blit was being started by the CPU before the previous one had finished. Odd – so how could this have worked on real hardware?

The author, David Jones, had a clever trick. DMA “nasty” was enabled, which stalled the CPU until the blit had finished, then the CPU would set up the next one.The problem with the core was we have 16 times the memory access slots as the original A500, and despite my best efforts the CPU was still getting in. I’ve just updated the core now which seems to resolve the problem. When in A500 or A1200 compatibility mode, the Gary module holds off any CPU access to chipset resources until a colour clock cycle (roughly 3MHz).  If a collision with a request from the DMA controller happens, the CPU is stalled to the next colour clock cycle – exactly as in the real machine. I also tweaked the soft CPU so it will only start cycles every 4 cycles (A500) or 2 clocks (A1200) mode.

When the system is put into “turbo” mode, these constraints are turned off and everything goes at full speed. As a result, Menace, Slamtilit AGA and Shadow of the Beast seem to work fine, although more testing to follow. I need to do a bit more tidying up, then back to the DVI / RTG (enhanced graphics card) work.

/MikeJ

 

 

Libs and Pacmans

I’ve been working on moving the existing (old) cores like Scramble and Asteroids over to the new Replay framework. While I was at it, I tidied up the library wrapper which has made the “plumbing” a lot simpler. I’ve started documentation and work on a webpage for this.

I also realized that my Pacman core was a little dated, other people had added Pengo and other variants to the hardware – so we needed to catch up, this is the original after all.

The Replay framework lets you easily change the ROM contents in an ini file :

ROM = roms_pengo/ep1689c.8,  0,    0x00000000
ROM = roms_pengo/ep1690b.7,  0,    0x00001000
ROM = roms_pengo/ep1691b.15, 0,    0x00002000

The command ROM is followed by a file name, a size (or 0 for all of it) and an address to upload to.

If the top bit is set in the address, the data is routed to an internal bus and used for loading internal FPGA memories. In this case it goes to external DRAM.

The Pacman core is a good starting point to see how the library DRAM controller is used, as well as the block RAM init blocks.

I discovered Pengo has additional ROMs, but also (and it’s not well documented) an additional SRAM

—  vram  0x000-0x3FF
—  cram  0x400-0x7FF
—  ram   0x800-0xBFF << PENGO ONLY
—  ram   0xC00-0xFFF

The game actually runs reasonably without this memory, so it took a while to find.

I also needed a way to enable/disable the extra Pengo features from the INI file (which also comes up as an option on the OSD – On Screen Display).

title  = “PacMan Setup”

item   = “Hardware”,        0x0000000F,static
option = “Pengo”,           0x00000001,default

Here, config bit 0 is set high for Pengo hardware. Static means a core reset is required to change this (done from the OSD or by selecting a new INI file)

I’ve got a little work to do still for LizWiz and MsPacman.

This code is checked in and available on the public SVN.

/MikeJ

Amiga core update

I made a few minor improvements to border sprite behaviour (fixes Banshee AGA). The core is in the Amiga news thread in the forum.

I intend to get the release SVN area sorted out in the next day or so…

Back from holiday

Right, returned from a brief holiday.

I’ve moved all the CAD projects and libraries over to my internal SVN repository. This was necessary to sync the work between the workstation and laptop, so I can get the daughter board and AGA debug board out to production.

Focus this week is shipping more boards, I know some of you are waiting patiently….

I’m also going to start adding project pages to this website, and see if I can fix a few more bugs in the Amiga core.

As always, check the forum for the latest gossip.

Amiga core update

I’ve been testing a new version of my Amiga AGA core. It’s checked into the private repository. I’m working this week to make binary releases (and source ASAP) on the public mirror.

 

The MIST AGA project has received some great updates recently, and I keep getting asked if I will pick up those fixes.

The answer is “no” – the code base is (mostly) different and I don’t have those bugs in. I may have different ones of course.

I am setting up a bug tracking system on here next so beta testers can log issues and I’ll fix them.

One thing we do work on together is the T68K CPU. So far I submitted one fix and received one fix back. Unfortunately Slam Tilt AGA still does not work on my core, and I am investigating.

Still testing and shipping boards, although I am having a few days holiday this week and I thank you for your continuing patience !

 

Survived the worlds biggest party

Well, just about. Glastonbury was amazing, but now I’ve sobered up, flown home and I have been busy testing boards all day.

I received an update from the Mist guys (we work on the 68K CPU together) and have updated the Amiga core. Still some issues, but moving forward.

I’ll be spending the next few days working on the website and sorting out how we do releases and handle versions. I’m also working on porting the remaining cores, and waiting for the AGA debug board (with real chips on) to come back so I can finish the Amiga core ‘tuning’.

 

Taking a short break

I’m off to a music festival in England (Glastonbury) today and I’ll be out of email contact for a few days.

You can see some pictures from last year here :

http://www.glastonburyfestivals.co.uk/gallery/

Back to shipping boards, finishing this website and getting more cores released next week.

Best,

MikeJ

Testing continues

I’ve been trying to catch up on the backlog of boards.

A number of developer boards have gone out this week. The boards below have all finished functional test and are going onto soak test, final inspection and then shipping to distributors.

(sorry for the poor quality picture, snapped it with my ‘phone)

/MikeJ

20150615_222906

 

New website

Moving the website to an alternative provider was a bit of a disaster. The performance was terrible, and the SVN solution they offered was not good enough.

So, it’s taken quite some work, but now we have set up svn.fpgaarcade.com and given the main website a bit of a revamp.

Still work in progress, but I’ve transferred all the original news posts (from 2004!) so far.