I finally got hold of a real UV-C erasing bulb, after buying one fake and getting another one cancelled due to postal service being withdrawn from the seller in China.
So I was able to burn TOS 1.04 and 2.06 onto the two halves of my ROM chip, but only 1.04 works for me on the H4. I read the contents of the chip back and compared the data and it's a match to the TOS 2.06 binary that I downloaded from http://www.avtandil.narod.ru/tose.html (tos206uk.zip).
Is there anything you need to know for this version of TOS to boot on the H4? I burned it at address 262,144 (0x40000) and it's not byte-swapped (it's the same byte order as 104, which works). I just get a completely black screen on startup.
Smonson's slow H4 build
Re: Smonson's slow H4 build
TOS 2.06 will not boot on the H4 without a 2.06 decoder for example on the beta IDE board.
Re: Smonson's slow H4 build
Aha! That's exactly what I needed to know, thanks!
Re: Smonson's slow H4 build
I have done some dedicated 206 decoder boards for such things as well
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Re: Smonson's slow H4 build
It makes sense in retrospect, I should have realised ahead of time. Since the STFM places TOS at 0xfc0000 and 0xffxxxx is, I think, all reserved for memory-mapped peripherals. I can easily live without TOS 2.06 for the time being.
Re: Smonson's slow H4 build
@Smonson , you should consider giving @cmorley's eprom emulator a try. It still requires a decode that provides the $0, $fc0000, and $e00000 as the eprom but its easier to use, holds 8 256k images and you don't need to pull the eprom out, burn it, and re-install.. then repeat if something went wrong. I just leave the USB cable connected so I can blast a new image and switch to it in seconds. I program sections that are not the selected image while the Atari is on and just press the reset. When you program one of 8 slots you can choose partial burn, byte swap, and a number of other things. Its a lot more convienient than using eproms especially if you working on a TOS code.
Re: Smonson's slow H4 build
You can create your own TOS E00000 decoder with a GAL16V8 and some old schematics IIRC. I think I have those somewhere.
/Troed
/Troed
- Attachments
-
- tos2_06r.zip
- (39.13 KiB) Downloaded 290 times
Re: Smonson's slow H4 build
My understanding is that 13.0pl1 is the latest version that supports CII?Smonson wrote: ↑Wed May 13, 2020 11:05 am... Unfortunately Quartus 12 no longer runs on the latest Ubuntu and I don't have enough laptop disk space to install another OS so that's a bummer, I will be constantly walking between my PC and the other room to try stuff. A very annoying decision on Intel's part for taking Cyclone-II support out of Quartus at version 12.1.
I'm not on the absolute latest (using Debian) but for now, I always got Quartus to work with some fiddling. Last time I installed Ubuntu 12 in a KVM, installed Quartus there, verified which shared libraries it drew (using ldd) and copied all of them into the Quartus bin directory of the native machine which worked fine.
And remember: Beethoven wrote his first symphony in C.
Re: Smonson's slow H4 build
Unfortunately 12.0sp2 is the last version for cyclone-2. It's a 32-bit application and that's the reason why the new Ubuntu can't run it. I can still run it on Windows actually - I didn't even think about that when I first mentioned it - probably because using Windows for software development is even more inconvenient than walking from room to room
Eventually I'll get a bigger SSD for my laptop, then I can run it in a VM.
Eventually I'll get a bigger SSD for my laptop, then I can run it in a VM.