EclaireXL

Started on a PBI component that will correctly communicate with the bus. Then this can be checked/simulated - and as a later stage I can do the core connection.

PBI looking good on simulation (bit itself). Based timings on the Freddie data sheet.
Made a start on wiring it up to the core. Need to remind myself how the enable strategy works and what they are all used for.

Initial idea is to just work on 1x mode, and delay the cpu until the 2nd half of the cycle, to find out if PBI takes over the bus or not. All writes will hit pbi, but reads will not (for now).

Integrated into the description and synthesising:-)

For now I took the strategy of delaying the cycle until we know if PBI wants to take over. Its enabled only in 1x speed for now.

Looking good on simulation now but does not run on the board. I think the issue is when pbi takes over the bus when a transaction is already in process.

This is all so complicated because I'm running the clock at 32x the original one, so have to carefully choreograph the timings on on pbi based on that.

Made several more fixes and the core no longer crashes with PBI enabled. However it all crashes when I plug in a cartridge! These worked without PBI support, but I replaced the cartridge logic too when I implemented this. Interestingly sometimes I receive the game screen - e.g. frogger logs or pole position road.

So one more day looking for bugs on the sim after which I hope it really will work. If not I'll have to fire up signaltap to see what is actually going on this weekend...

foft wrote:

Made several more fixes and the core no longer crashes with PBI enabled. However it all crashes when I plug in a cartridge! These worked without PBI support, but I replaced the cartridge logic too when I implemented this. Interestingly sometimes I receive the game screen - e.g. frogger logs or pole position road.

So one more day looking for bugs on the sim after which I hope it really will work. If not I'll have to fire up signaltap to see what is actually going on this weekend...

Congratulations! This is real good news.

The core blows up with signaltap2 enabled! Looks great on sim, but I can't see what is going wrong on the actual hardware:-(

I started to bisect to find the problem - and found the core stops working when connecting RAS and CAS! Which are largely just for show, I doubt anyone will really use a 1064... Anyway I checked the pin assignments and found a bunch of duplicates which may be the cause of the woes.

Still no luck with signaltap, so got the real logic analyzer on the GPIOs to debug. Squashed one sync bug but still no dice. But now confident I can get the values I need out where I can see them at least.

PBI lives!!

Still some debugging to do but so far...
Cartridges are working again, which is a good sign (these are now via the PBI component)
Turbo freezer works - sort of! Sometimes is seems inactive and the memory expansion doesn't seem to work. But I have plugged in the uno cart and turbo freezer and it seems to work.

pbi21.sof for anyone brave (new board only for now, but will port soon)

Interesting the acid test now fails with this core, which explains the blips I got when running real cartridges before. So probably some antic timings are wrong when the active cycle is in the 2nd colour clock of the cycle.

foft wrote:

Interesting the acid test now fails with this core, which explains the blips I got when running real cartridges before. So probably some antic timings are wrong when the active cycle is in the 2nd colour clock of the cycle.

Great news!!!

Some progress in antic timings which are broken by this. I found I am using a delay shift register to wait 32 cycles (48 in one case!) on a write to a bunch of registers. This isn't really ideal since depending on memory timings the next cpu cycle could be 28 or 34 cycles later etc! So I'll change these to be based on 'original machine cycles' instead which will mean that the pbi delay does not break the timings. I've started on this but need to simulate to verify because so far it makes the acid test work.

Some info from Hias on the turbo freezer:
"Reset on the freezer runs through a synchronizer, clocked by phi2. IIRC 2 clock cycles after rst_n=0 freezer is in reset state. It then snoops the bus, when the freezer button is pressed it looks for 2 consecutive accesses to fff8-ffff and will intercept the second one (high byte of interrupt/reset vector). It doesn't assert irq, only passively listens and waits for an interrupt to occur and the rom vector access."

Still not got signaltap going, so I will modify the core to output address/data over the GPIO. Perhaps 4 bits at a time (1 nibble) so I can see/read easily address/data on the trace. I can't capture the lot easily since my logic analyzer has only 16 lines.

Fixed some clear cycle delay bugs in antic and simulated. This fixed NMIEN and WSYNC tests in acid, however there are still 4 failing. Work out why...

I could do with converting the acid test suite into testbenches really!

I've been squashing test failures related to moving the cpu clock later in the '6502 cycle' due to PBI. None of these should have changed anything, they are all silly bugs. Mostly fixed, though the last one highlighted some issues with my DMA clock setup. I started the normal dma clock at cycle 0x21. However if the mode is changed to narrow then the deadline to start this clock is cycle 0x22! Moving the CPU back 16 cycles puts me into cycle 0x22. I hacked the DMA clock for now but this is clearly the wrong solution. Its meant to be combinatorial logic, then 2 cycle delay on start. I now have a 1 cycle delay for start... This will be tricky to unravel.

Well that horrible dma clock patch led to a complete acid pass except for a gtia failure. I see in gtia I have colour clock delays on register writes will lead to exactly this kind of problem. So I need to adjust all of those delays to be in terms of phi2 instead of colour clocks.

Synced gtia delays to end of original 6502 cycle time and now acid is passing again.

I took a look at the turbo freezer on signaltap, I can't see it even trying to pull refresh after a reset. So I guess I need to check I'm still feeding it valid inputs... Oddly oldos mode DOES work! So ... weird...

First cut released as v9. Sure there are some bugs, try at your own risk!

I added output of internal reads to the bus. I also fixed some cases around writes.

Now the external turbo freezer works well enough to save and load state to disk. However the internal freezer still crashes. The reset problem remains though, I tried resetting the pbi layer at the same time as the atari core with no impact.

(pbi31.sof for anyone wanting to try)

Woohoo, freezer is working after reset - and ramdisk is working from freezer!

Please now test some other devices - and let me know how you get on:-) I can't guarantee its safe but the fact the freezer seems to work is a good sign...

Turn on data write to bus earlier, for things that snap it early (like IDE2+).
Register MPD_N before feeding to the address decoder and disable it when disabled.

Hias tried out PBI on the v1.

Surprise: Turbo freezer didn't work! Mine works perfectly on v2...

He investigated and found three things:
i) REF_N pullup is a little low, so with any increased capacitance it takes too long to rise. We should change this resistor from 4k7 to 1k8-2k2. Owners of the v1 board may wish to make this mod.
ii) PHI2 duty cycle approximation causes some of the monocycle timed devices to fail. I adjusted this from 43.8% to 46.9% and this fixes his issues. On a real 6502 its 47.25%, but since I'm approximating intra cycle timing with a 32x clock rate I can't get closer easily.
iii) Antic refresh is not yet supported, I should probably output this in case people connect legacy memory upgrades. Does 1064 use it?

Excellent!

Added antic refresh cycles