exxos's Atari, Amiga & retro forum

Been looking at the TTRAMTOS program and it looks like its patching all sorts in TOS :roll: problem is, its all hardwired into the code, so any TOS version we compile will break its patch locations :roll:

So when @Icky catches up with my 27 emails, I hope we can actually fix TOS to stop all this sillyness and not have to bother with TOS patch bodges at all.

exxos wrote: 05 May 2021 22:45 Been looking at the TTRAMTOS program and it looks like its patching all sorts in TOS :roll: problem is, its all hardwired into the code, so any TOS version we compile will break its patch locations :roll:

So when @Icky catches up with my 27 emails, I hope we can actually fix TOS to stop all this sillyness and not have to bother with TOS patch bodges at all.

One of my (many and far off) long term goals is to patch TOS4 to allow software blitting again. That'd be a precursor to only using hardware blitting when going from ST to ST RAM and therefore, in effect, baking in BLITFIX.

Whilst none of this work is directly related, hopefully it give the whole TOS patching movement a bit more impetus. :)

BW

The plot thickens... The floppy malfunctions only when the caches are on, but only when TOS is running from fast ram...BUT.. It only malfunctions when the -38 DMA is used.. When I swapped to a IMP DMA everything works fine... Which makes no sense at all...

exxos wrote: 07 May 2021 11:37 The plot thickens... The floppy malfunctions only when the caches are on, but only when TOS is running from fast ram...BUT.. It only malfunctions when the -38 DMA is used.. When I swapped to a IMP DMA everything works fine... Which makes no sense at all...

Ah, when I get a couple of these boards from you along with the H5C (and the rest of the bits from Farnell!) then I might be in a position to compare/confirm your findings - I have a few IMP DMA chips as well as the more standard -38 devices...

JezC wrote: 29 Jun 2021 17:42 Ah, when I get a couple of these boards from you along with the H5C (and the rest of the bits from Farnell!) then I might be in a position to compare/confirm your findings - I have a few IMP DMA chips as well as the more standard -38 devices...

Yeah, its a odd one. 2 brands of DMA causing different things.. :shrug:

@exxos Well, won't be the first time and probably not the last.

If we can find a working combination in the meantime then we can get other people going and try to dig further from there.

At least it works...and I wonder if the floppy problems I have with the rev 2 TF536 are related?
Didn't have the IMP DMA to try before... might be worth a go now that I do....

exxos wrote: 07 May 2021 11:37 The plot thickens... The floppy malfunctions only when the caches are on, but only when TOS is running from fast ram...BUT.. It only malfunctions when the -38 DMA is used.. When I swapped to a IMP DMA everything works fine... Which makes no sense at all...

Well, it could be the noise or voltage level tolerances in the chip design It could be just the attenuation or length of the track runs in the chip or the layout of the components. Or it could be the mask registration was slightly different on the production line etc. The DMA chip seems marginal at the best of times.

I think TOS just doesn't like running from fast ram. Problem being as well, programs like maprom use PP's hacking code to patch TOS to run at all. As anders is unlikely to develop the software further, it's just not gong to be fixed. Even so I'm not sure it's worth the trouble anyway.

TOS could be compiled to run at a different address but that would take some doing, would need some sort of bootloader to load TOS into RAM..it's just one big messy hackjob. I'm not sure how EMUTOS operates with fast ram or how to copy it there. Programs seem non-existent.

I think aside from the 32bit aspect, I'll think about copying ROM into SRAM. In fact flashy clock was designed to do just that. But it didn't happen as I ran out of space in the PLD :roll:

I'm plotting a 3.3v board for the H5. Mostly because its needed for the SEC booster. Plus when we get faster bus speeder on the H5, this board is ready to go anyway. Point being ROM will still run from its proper address space only it will be copied to a small SRAM on power up. Then no ugly code hacks are needed at all.

exxos wrote: 28 Jul 2021 15:56 I think TOS just doesn't like running from fast ram. Problem being as well, programs like maprom use PP's hacking code to patch TOS to run at all. As anders is unlikely to develop the software further, it's just not gong to be fixed. Even so I'm not sure it's worth the trouble anyway.

That's interesting. I'm not much of an assembly coder so I wasn't clear what was going on, but I was looking at MapROM as an example of MMU usage and didn't notice TOS patches.

https://github.com/agranlund/tftools/bl ... C/MAPROM.S

I've not really understood the problem entirely, but MapROM will obviously only work with the CPU. Any DMA access to ROM will still go to the motherboard-accessible location. Any chance that's an issue? (Although I can't immediately see how the floppy would need to access ROM or the low RAM.)

BW

Badwolf wrote: 28 Jul 2021 16:40
That's interesting. I'm not much of an assembly coder so I wasn't clear what was going on, but I was looking at MapROM as an example of MMU usage and didn't notice TOS patches.

https://github.com/agranlund/tftools/bl ... C/MAPROM.S

I don't remember exactly, but i think TOS does jumps to specific ROM locations, rather than jumps to labels or whatever. So the patch table has a list of addresses to patch.. Which varies on TOS version, language etc so it pretty much renders maprom useless as it uses the patch tables PP created. I never got RAMTOS to work with any ROM image. But problem is, I doubt it was ever tested much. There could be other ROM jumps not patched which may only show up on a 030 CPU. As you can imagine, the whole concept is a hacky mess.