ST536 STE EDITION

[exxos]

Been playing around but given up for now. Something seems screwy as now the shadow logic is causing EMUTOS to crash on all sorts of crazy addresses. So it's like the main bus is trashed now, but no idea how

As EMUTOS doesn't use the blitter I removed the logic for that. So only the CPU can access ROM. Then after ROM copy to RAM it totally disabled the ROM decode logic for ROM and directs the decode to the sdram controller. Where it changes the ROM address to RAM . So the SDRAM controller just thinks it's doing stuff as normal... Only it doesn't seem to work like that.

Simple SRAM bank switching should work. But there's the risk it's the switch causing the crash for some reason.. and that be a lot time and expense for essentially an experiment

I suppose I could put some SRAM onto a ROM board as ROM has all the signals I need. Then I've got 2 free IO pads I can bodge across for CS and RW... That's likely the simplest option to try the idea. But wouldn't be 32bit which could be a factor

[JezC]

Could you reach out to some of the EmuTOS developers to see if they can suggest other alternatives?

For example, I'm sure there is a way to build a version of EmuTOS to load into RAM (there's a .prg version of it available already IIRC) so maybe they can help with a test build to get around the issues you are facing & just have a RAM resident version (that can run in TTRAM) that is loaded from the ROM itself into TTRAM & then runs within the TTRAM?

I know it's a bit different than what you are trying to accomplish right now...but maybe it's an acceptable compromise for this first iteration?

I'd for one would be OK to have the STE536 that bit earlier even if there is a bit of a compromise over the choice of OS version for the best performance.

Just an idea - maybe you can ask the wider customer base on how they would feel about the choice?
Feel free to ignore it - I won't take offence if you do

[exxos]

@JezC MAPROM can still be used to copy TOS or EMUTOS to TTram.. So it's not a issue really..

Just I want to move away from MAPROM as I don't understand it and there's no maintainers etc. So just copying ROM to RAM as a mirror would be a simple solution.. only it turned out to be not so simple in the end I mean all I do is multiplex 2 different addresses really....It shouldn't be that difficult

Mostly the BETA testers need to all be working before I consider a batch. But funds are limited and I need to pay off my credit card.. I need to buy like 100 030 CPUs somehow yet.. and test them all.. and the DFB1X n batch will be here soon... So time and funds are going to be limited for the next few months no doubt anyway.

[exxos]

Thought id try inverting the ram clock as it would work fine otherwise now but that resulted in it not even booting now. It doesn't make a lot of sense really.

I've disabled burst just in case. TTram would test fine anyway with the address translation logic. So hard to think it's only causing problems with the address translation logic. The address translation was likely wrong before as well.

I can only assume that the address translation simply isn't fast enough and when ROM is in play it adds a bit more delays. But also the address should be stable when /AS30 is low. But at that point I'm changing the address. If it happens near the clock edge (100MHz) it likely causes an random address during translation. Which is probably what I saw when EMUTOS crashed, as the crash dump has allsorts of weird addresses.

"Give it up as a bad job" as we used to say in our old workshop. It's just not worth to keep throwing away time on it.

So it's just a matter of seeing where the current BETA testers are at now.

I've got 4 of the current boards which I'll add into the store soon. These will need the PLD changing and PGA socket. So if you're not good at soldering, this build isn't for you. You'll need to know how to program the PLD and ROM yourself as I don't have time to hold people's hands with this stuff. You'll be classed as a BETA tester at this point.

[Badwolf]

BUT it locks up when copy_done goes high, so I assume the address translation isn't working, or the CPU isn't in 50mhz mode during the shadow rom access. Or the idea simply doesn't work, or i've done something dumb.

Without a big picture it's not likely anyone will be able to see exactly where this has gone wrong.

I do do a similar thing with DSTB1. 'AltROM', I call it. It too uses an SDRAM controller and remaps the address, but I doubt that's the source of the problem.

You have so many moving parts to keep track of that only one not behaving as you'd expect it to will cause a failure. Hence the big picture.

Off the top of my head I can think at least of

• * enabling the translation
  * disabling the ROMCE
  * stopping the combo chip seeing the access
  * still triggering the SDRAM despite the translation
  * keeping all the above consistent

With a card as complex as this one, I'd consider that a future upgrade rather than something to worry about now. And the last one will be a kicker.


BTW, I hope to get onto the CPLD changeover next week, with a fair wind!

BW

[exxos]

You have so many moving parts to keep track of that only one not behaving as you'd expect it to will cause a failure. Hence the big picture.
Off the top of my head I can think at least of

Yep that's the jist. In one respect it's incredasbly simple... In another, not so much

I'm at my girlfriends today. Giving my mind a break. I'm hearing the latest on the Idaho murders currently

I think the main problem is the address is changing while AS30 is low.. I can fix that later but I doubt it's going to be that simple..

With a card as complex as this one, I'd consider that a future upgrade rather than something to worry about now. And the last one will be a kicker.

Yep. I've got so many things to do.. plowing lots of time into a single problem isn't a good use of my time..

BTW, I hope to get onto the CPLD changeover next week, with a fair wind!

[exxos]

Code: Select all

wire shadow_enable = copy_done & ~TOSCE_RAW; //& ~AS30  Enable for TOS206 addresses

//When shadow_enable is high and A_IN is in the 0xE00000 - 0xEFFFFF range,
//A_IN = 0xE00000 ? A_INT = 0x04F00000
//A_IN = 0xEFFFFF ? A_INT = 0x04FFFFFF
//A_IN = 0xExxxxx ? A_INT = 0x04Fxxxxx
wire [29:0] A_INT = (shadow_enable && (A_IN[29:20] == 10'h038)) ? {10'h04F, A_IN[19:0]} : A_IN;

Copy $Exxxxx to $4Fxxxxx works. Verified in STOS and asm copy program

copy_done bit goes high then locks up

A_IN is the 68030 address bus. Routed though A_INT. Normal TTram works fine.

Slowed down A_INT by 1 clock and TTram still works fine. so didn't appear to be a delay problem on the address bus.

tried slowing down STERM and forcing it low on shadow access.. no change.

ram_decode (TTram) when Low sets the CPU to high-speed, I have a clause in that for TOS ROM decode.
So the ST RAM module will still trigger, and the address gets translated so as far as anything is concerned in the ST RAM module,
it is simply accessing $4Fxxxxx. The CPU still things this accessing $E00000

Ram_decode isolates the STE bus from the CPU anyway. it also puts the CPU into 50MHz mode.

I've also prevented the STE from seeing any ROM access.. even gated DTACK from reaching the CPU. (generated my own, also gated)

So CPU accesses $Exxxxx, address gets translated to $4Fxxxxx, SDRam decodes the address as normal, issues STERM - done.
ROM is isolated from the CPU bus anyway.

But when copy_done goes high, it just locks right up

IMG_3181.JPG (28.87 KiB) Viewed 1136 times

At that point is simply accesses $4F80000 to trigger copy_done in the firmware.

The programme next should simply say press any key to continue but it doesn't get that far..

Also realise that all the AI models don't understand verilog for some reason. BUT the GPT coding module seems to "get it". But that concluded "it should work"

If I force my copy_done flag to zero, everything works as it should. So its not like i've seriously broken the SDRAM code. I've basically done almost nothing other than what I posted above and the copy_done code.

My only thought is the address translation line just doesn't do what I think it's doing

EMUTOS doesn't list any errors, just as shown in the image. STOS, if I copy the ROM , then PEEK $4F80000 to set copy_done, STOS just across "bus error" constantly. So its like my shadow ROM simply isn't working.....

[Badwolf]

Maybe try not mapping 0x00Exxxxx on activation, but map 0x00Dxxxxx instead.

Hopefully now you don't crash as the OS is buggered and you can do some peeking to test things.

BW

[exxos]

Yeah I suppose I could try a remap to somewhere else. I've pretty much given up on it now. I mean the ROM copies fine , so it should only need bank switching basically... I'm only fiddling the high bits at the end of the day

In suppose I could remap to the original address as well to see if that locks up on switching .

EDIT:

Oddly

Code: Select all

wire [29:0] A_INT = shadow_enable ? A_IN : A_IN;

Doesn't work either

Default config (no switch) works fine

Code: Select all

wire shadow_enable =1'b0;
wire [29:0] A_INT = shadow_enable ? A_IN : A_IN;

Oddly my copy program completes, but then locks up before desktop..

Code: Select all

wire shadow_enable =1'b1;
wire [29:0] A_INT = shadow_enable ? A_IN : A_IN;

Must be some timing error somewhere. But I even tried clocking that by the 100MHz clock and made no odds. I can't believe it takes more than 10ns with shadow_enable =1'b1 ... I dunno..

Oddly it doesn't lockup

Code: Select all

wire [29:0] A_INT = 1'b1 ? A_IN : A_IN;

if I run from floppy not IDE..

I just go back to that the extra delay on A[X] is the cause of it all. Can't really fix that.

I suppose the addresses as they going via the PLD are adding a delay. So it's possible even if I add a tiny bit of logic in it's path, it's making it invalid when AS goes low

[exxos]

I'm shelving the ROM copy idea of the time being because of the amount of time it is taking up..

So I found out the external blitter type motherboard to use as a second test machine.. I had to change the simms out for some sockets. The board boots up. So it was a simple one to get up and running!

IMG_3185.JPG (441.42 KiB) Viewed 927 times

IMG_3186.JPG (394.75 KiB) Viewed 927 times

IMG_3187.JPG (310.07 KiB) Viewed 927 times

Interestingly this has the updated DMA chip as well.

IMG_3188.JPG (329.24 KiB) Viewed 924 times