SAM replacement - there!

[sixxie]

Edit: it's released now

I'll post this here too...

Working on a SAM replacement - not as a product really, more to prove the concept and work out the bugs so it can be used in future designs.

At first I thought the reset detection wasn't working, but after bodging around that I put things back as they were in the code and... it worked. So that's nice. Unless it only started working because I poked the pin against the pad, in which case naughty JLCPCB not setting light to pad shaped solder paste. Figure more likely my problem though

There were some video counter latchups on reset, but I appear to have sorted those.

Refresh seems to be ok - certainly it survives 30+ seconds of holding in the reset button.

All three speed modes are supported, but Stew's refresh tester shows the LDA instructions instead of the text while running, so clearly I'm transitioning slow->fast a bit too enthusiastically. http://www.6809.org.uk/tmp/samx4-wip/samx4.mp4

Only 64K memory type supported as things stand. I'll maybe look at 16K, but getting what's there "just right" will take priority. OTOH I did include work-a-like support for Stew's 256K Banker Board. I'll have to test that at some point - ordered some appropriate DRAMs off ebay, let's see if they work. Wishing I'd connected pin 1 of the DRAMs together on the repro motherboard... Bodge wires ahead.

Oh and video address "glitching" doesn't work yet - it's a bit too "ideal".

Progress though! At first I thought it was completely inoperable (no video), until I realised the relay was clicking... So I typed MOTOR ON and got a second wind!

Once I've worked out the last little bits I'll upload the schematic/pcb and VHDL (probably make the VHDL share-a-like or GPL too).

Currently using about 120/144 macrocells on an XC95144XL (ISE configured for speed, so can probably save a bunch by configuring for density - I doubt it would make much difference to operation).

Oh, and hidden in the picture by a probe is a little 14.31818MHz oscillator. I could have taken that from the motherboard but only because I used a TTL output oscillator myself - I don't know right now how you interface a crystal to such a thing

[bluearcus]

That's super cool.

Really hope the density option pulls back a load of macrocells, as some headroom on this design would open up some amazing possibilities.

[tjewell]

is all I can say ...

[sixxie]

That's super cool.

Really hope the density option pulls back a load of macrocells, as some headroom on this design would open up some amazing possibilities.

Afraid to say it ends up using more somehow

Of course if you were going to take this and use it for a more modern recreation, you'd rip out the refresh stuff completely and not bother having to multiplex row/column etc. so you'd claw some space back that way.

Edit: of course I'm also limiting it to using the pinout I settled on for getting the PCBs made... You get more space if you let it have free reign over the pinning Edit to edit: no, you don't! That's pretty mad, for some reason letting ISE do what it wants uses more of everything!

Edit^3: I can drop macrocell usage to 109 by forcing it to use a more compact state machine representation, so there's some flexibility there.

[bluearcus]

My thoughts were making it do something gime or 6829-y with an external sram and a latch / transceiver.

Then you could meet your "it's still a dragon" test but do nice os9 level 2-y stuff. Essentially a modern integrated version of the Bob Hall MMUs.

However, it sounds like space is probably at too much of a premium for that, so falling back on his "SAM extender / fooler" approaches may be the only way in the modern climate of no CPLDs > 150 cells for a sane price!

[sixxie]

Meh. My glitching is glitching:

http://www.6809.org.uk/tmp/samx4-wip/glitch.mp4

Macrocell usage down to 111 though (98 with compact FSM!) as I realised I was being dumb with a few things.

[bluearcus]

Nice reductive action. Fingers crossed for glitch de-glitch.

Is that 98 with a stu-banker integrated?

[sixxie]

http://www.6809.org.uk/tmp/samx4-wip/glitchy-less.mp4

Getting there. Still a slight wobble

99... and yeah that's with the banker board registers and 9-bit refresh (overkill, i know, but you only save one cell cutting it down to 8)

[sorchard]

Ah, so this is where all the fun is happening! That's awesome

I could be wrong but I think the majority of 256K drams had 8 bit refresh. After that the industry moved to CBR refresh and you didn't need a refresh counter any more.

I'm curious to know if the logic to recreate the glitching is using up much resource or if you can get some of it for free by ripple clocking the counters like the original SAM? The synthesis tool may complain about timing closure but that's not likely to be relevant at this sort of speed.

[sixxie]

Ah, so this is where all the fun is happening! That's awesome

I could be wrong but I think the majority of 256K drams had 8 bit refresh.

Yeah I spotted that but it’s almost no extra to do 9.

I'm curious to know if the logic to recreate the glitching is using up much resource or if you can get some of it for free by ripple clocking the counters like the original SAM? The synthesis tool may complain about timing closure but that's not likely to be relevant at this sort of speed.

Not much at all as it stands, but that might be why it doesn’t work properly!

I’m storing copies of V2 and V1 and updating them on the other edge to the register updates then have some simple logic to force use of 0 or B4 while they are different.

Currently away from the computer for a couple of days but I can paste the relevant bit when I get home.

Been wondering if I need to properly phase Y update then X update. Seems unlikely but I might see if it makes a difference. All has to happen before the next DA0 change window…