Falcon TOS EPROM?

[Rustynutt]

Keep this short and sweet, no matter how out of character it is

Some years ago (many) when fooling around with faster PAL and GALs in attempt to boost speed above 44mHZ on a Nemesis/Afterburner/NOVA FX Falcon, purchased a few AT27C4096 55ns eproms to work with.

Have seen comments like get such and such, they are faster than eproms.

Do I have junk, with respect to the application? 55ns seems quick.

Has anyone yet laied out a PCB design for a multi-ROM Falcon?

[Greenious]

AT27C4096 are EPROMs, and yes, 55ns are about as fast as the technology get, if you want faster you need to go with EEPROMs or Flash-EPROMs.

They are not junk, just overkill for standard F030's, although the speed should enable an overclocked cpu rom-access at 32Mhz, giving a notable speed increase in GEM environments.

Afaik, noone has made a multi-ROM solution for F030, and tbh, I am not sure it would be very useful. Many accelerators offer fastram, moving TOS into fastram, or using it for alternative OS is way more effective for speed. You don't need it for compatibility issues either.

ST/STE is a different matter, there a TOS switcher is useful, given compatibility issues with old software, although most have been fixed today so it is far from the almost necessity it once was.

[Rustynutt]

Thank you Greenious!

The multiple ROM thought is to divide a MagX and TOS enviroment. At this point in a Falcons life, once a specifically legacy setup is achieved, having a machine specific ROM useful... A thought.

The above eprom is 4mb, correct?
Could two O/S reside on one ROM, and use cartridge port logic to point where on the ROM to begin boot execution?

MultiTos is disk bootable, but if stored in ROM, could it be called to boot from the cartridge port?

Thanks

[Rustynutt]

Last night digging and filing years of notes, found a blurb where TOS TO RAM loads TOS into RAM address space. Does this util use known TOS 4.04 to size the address, or does it just look at where TOS is suppose to be on ROM and load what ever size TOS, or MagiC OS it finds?
Thanks again.

[Rustynutt]

The only debugger I've ever used to poke around in memory is BSS Debug. Most the others are for hardcore assembly programmers. I remember BSS allowing line by line real time execution, and fairly easy to find in memory where code is executed. You could alter that memory, and view real time change. The possibility to copy the machine lanugage to a new file also exist. That was some years back, kind of foggy there.

If paitent, at some point I usually tie questions and thoughts together, takes me a bit

[Greenious]

The above eprom is 4mb, correct?
Could two O/S reside on one ROM, and use cartridge port logic to point where on the ROM to begin boot execution?

MultiTos is disk bootable, but if stored in ROM, could it be called to boot from the cartridge port?

It is 4megabit, which is 512kilobyte. I doubt there is enough room i there to add another OS besides 4.04.
You need a bigger EPROM, but afaik there is none in PLCC44 package, which means you would need a PLCC44 plug/adapter and use a 27c080 or 27c160 for multiple TOS options...

But yes, bigger eproms is what is used on ST/STE to fit multiple tos, the principle is very simple, and if you look at my guides (see link in my sig) you will find a guide for the STE, which pretty much should be selfexplanatory on how it works.

Maximum size for the cartridge is 128kilobyte, in theory you could have an OS boot from it, you can use a cartridge like a read-only kind of harddrive, it will be accessible from desktop as lower case c, and is bootable... but in reality 128kb is too small to fit any OS.

[Greenious]

Last night digging and filing years of notes, found a blurb where TOS TO RAM loads TOS into RAM address space. Does this util use known TOS 4.04 to size the address, or does it just look at where TOS is suppose to be on ROM and load what ever size TOS, or MagiC OS it finds?
Thanks again.

Well, if you move TOS out of romspace, it has to be relocated to the new adress space it is using, So the TOStoRAM software needs a relocation table to adjust all direct rom space adresses to the new ones. I'm not sure if there is relocating tables in TOS, or the creator of the software has to build one specifically for each TOS version...

If you look at the TS header, the first 8 bytes is starting PC and SP for the CPU, and the frst 8 bytes of romspace is mirrored at $0 thru $7 in ram, and when the CPU first boots up, that is where it will look for starting up..

[ThorstenOtto]

but in reality 128kb is too small to fit any OS.

Not quite EmuTOS has an option to be build as cartridge, and crashman actually is offering such a thing, see viewtopic.php?f=33&t=33974&p=348216

Is has no AES and Desktop, however, and boots into a simple cli instead.

[ThorstenOtto]

I'm not sure if there is relocating tables in TOS, or the creator of the software has to build one specifically for each TOS version...

No, there aren't any. All the programs that are able to load TOS into RAM carry relocation tables with them, for the known TOS versions.

[czietz]

Well, if you move TOS out of romspace, it has to be relocated to the new adress space it is using, So the TOStoRAM software needs a relocation table to adjust all direct rom space adresses to the new ones. I'm not sure if there is relocating tables in TOS, or the creator of the software has to build one specifically for each TOS version...

On the Falcon, shouldn't software like ROMSPEED (http://www.seimet.de/atari/en/index.html) be able to load TOS into RAM without relocating?

[Rustynutt]

I meant only use the cart as a soft switch to load a specific OS from the TOS ROM, as when the Falcon comes up, it executes code from the cart first. A menu could come up with a option for OS, then cart tell which TOS to load. Maybe use the KYB ASCI to switch active ROM on two chip PCB.

[Rustynutt]

Also, with 4MB space, could UIS be included below TOS in ROM ? I would like to have all NOVA and Afterburner auto prgs in ROM executed as there are never changes to the set up with NVDI included. Those never change, HH Driver would be nice too. In the event of a hard disk failure, an Afterburner/Nova would always boot to NOVA graphics desktop.

[Greenious]

Well, if you move TOS out of romspace, it has to be relocated to the new adress space it is using, So the TOStoRAM software needs a relocation table to adjust all direct rom space adresses to the new ones. I'm not sure if there is relocating tables in TOS, or the creator of the software has to build one specifically for each TOS version...

On the Falcon, shouldn't software like ROMSPEED (http://www.seimet.de/atari/en/index.html) be able to load TOS into RAM without relocating?

Technically he isn't relocating TOS...

He uses the 68030 pmmu to relocate the ram instead... which is why it only works on TT and Falcon. lol

But I didn't think about that possibility at first.

[Greenious]

I meant only use the cart as a soft switch to load a specific OS from the TOS ROM, as when the Falcon comes up, it executes code from the cart first. A menu could come up with a option for OS, then cart tell which TOS to load. Maybe use the KYB ASCI to switch active ROM on two chip PCB.

Yes, you could do that I suppose, but a simple switch is more simple and definately cheaper.

[Greenious]

Also, with 4MB space, could UIS be included below TOS in ROM ? I would like to have all NOVA and Afterburner auto prgs in ROM executed as there are never changes to the set up with NVDI included. Those never change, HH Driver would be nice too. In the event of a hard disk failure, an Afterburner/Nova would always boot to NOVA graphics desktop.

It's not 4 megabyte, it's 4 megabit.

The TOS adress space is only 512kb large aswell. you will only be able to access 512kb of whatever rom you fit.

as for patching TOS up with UIS, drivers and whatnot from start I really don't know how much room there's left, I think most is used up. However, you could possibly rip out the resources for french, german etc and only keep english, which would give some room for extras.

But how to actually do the patches, I have no ideas.

[Greenious]

but in reality 128kb is too small to fit any OS.

Not quite EmuTOS has an option to be build as cartridge, and crashman actually is offering such a thing, see http://atari-forum.com/viewtopic.php?f= ... 4&p=348216

Is has no AES and Desktop, however, and boots into a simple cli instead.

Heh, I forgot about that one. Kinda cool...

[Rustynutt]

Sorry, I keep mixing megabit amd megabyte Ummm, adpter with larger eprom...
Thanks!

[joska]

IIRC there is nothing else than ROM in the e00000-efffff address range, so a 1Mb ROM should be possible. You'd probably need to add an address decoder for the upper 1/2Mb.

It should be perfectly possible to create a board with 1Mb EEPROM and some logic (one GAL) with address decoder for the e80000-efffff address range. Then you could flash one "bank" while running TOS from the other, similar to what the ST MonSTer card does.

Having such a thing would be extremely useful for us Afterburner users (all four of us ).

[Rustynutt]

Yes, unless one knows "our pain" with all the AB and NOVA set up, difficult to understand why having it all on ROM would be nice

[Rustynutt]

Removing the Eagle Sonic, got interested in the Falcon bus PAL and GAL set up. While I wouldn't know how to actually program them, tracing out the lines, and comparing to schematics, the are actually pretty simple in function. Kind of provide a "informatiebord" (Dutch ) for other processors on board .
The Field Service Manual really doesn't go into detail what actually goes on at boot.
I don't understand what component actually "looks for a magic number" at the cartridge port at boot, then if it's not found, boot from ROM.
A more step by step detailed of what occurs at boot, what initializes first and so on would help me a lot.
If the CPU comes up first, isn't one of the first thing is does is RST, then continue to execute?
The CPU obviously doesn't know anything about the cart port, what processor, or logic points it that way when it comes out of reset?

I know at one point Rodolphe had considered just removing them and putting all this in the CT60 load, not sure why he didn't, but after following the train route, prolly just didn't seem worth the time as it doesn't look like performance is a factor in their function.

Short and sweet, right

[Greenious]

TOS always boot first. The first 8 bytes of TOS romspace is mirrored to $0-$7, which sets the starting PC and SP for the CPU.

After TOS starts, it more or less immediately check the cartridge for the "magic number" and if found, jumps there. After that it checks memvalid & the resetvector. Then it starts initialising GEM before checking cartridge again (if it is setup as a programcartridge, a read only kind of hdd), IDE/SCSI/Floppy is next

something like that

[Rustynutt]

In the big rom discussed, thought getting hd driver, for us AB users prolly 7.56 to boot just to load into memory, then again in the autofolder to set uo drives actually connected and hg driver configs, if Uwe wouldn't mind this. These roms really would machine specific.
Thank you for the boot sequence.
Has anyone ever identified the first bits if TOS that are incompatible with the 060 code?
Thank you

[Rustynutt]

Followed your link, more to play with. Thanks!

[joska]

Has anyone ever identified the first bits if TOS that are incompatible with the 060 code?

I would assume that would be the MMU setup code. Not sure if anybody has confirmed how the AB is able to boot plain 4.04, but I guess the CPLD's are "NOP-ing" the PMMU instructions.

Compilable sources for 4.04 are floating around on the net, and the sources for Doug's AB toolkit is also available. It should be possible for someone (more skilled than me!) to combine these to make an AB/040 compatible TOS. Oh, the Nova VDI sources are out there as well. Should be possible to integrate this into TOS as well.

[Cyprian]

. Oh, the Nova VDI sources are out there as well.

I wasn't able find them? Do you have any link? thx