rpineau Posted July 21, 2015 Share Posted July 21, 2015 (edited) I have been working on a 68020 card for my MegaSTE. I intend to make version for STF (which should also work on Mega ST) and STE once this proto is done and tested. exxos allowed me to post the progress on his website (instead of doing it on mine as I wanted to keep this with the V2 booster we're working on as some of the CPLD code is common to the 2 projects). You can find the current status there : http://www.exxoshost.co.uk/atari/last/020BOOSTER/ I'll update this page as I make progress and will also do some quick status update here (mostly post about the issue I have and ask for help ). So far the card is assembled and I need to finish the CPLD code. Then the testing starts .... as well as the problems Regards, Rodolphe Edited July 21, 2015 by rpineau 2 Quote Link to comment Share on other sites More sharing options...
ParanoidLittleMan Posted July 21, 2015 Share Posted July 21, 2015 I don't want to be negative about this exciting project, but must ask: why 68020 ? While we have 68030 in TT and Falcon. That would make it much more compatible with existing SW. Main difference is PMMU. Someone may say that it is not big deal, but disabling PMMU code may be extra task. Plus, PMMU can do lot of useful things, like fast bank switching, memory protection ... Is reason price, availability ? Quote Link to comment Share on other sites More sharing options...
rpineau Posted July 21, 2015 Author Share Posted July 21, 2015 The 68020 is directly compatible with TOS 2.06 and the most compatible with the 68000. Also as I said, I'm doing this to learn.. so start small, the build bigger things. The 68030 is more "complicated" to adapt to the 68000 bus and if we want to make use of all the feature including burst memory access, it gets even more complicated. Add to this that it would require a patched TOS 3.06 and this becomes a way bigger project than what I have time for. If someone wants to do a 68030 board, go ahead (Rodolphe Czuba even offered at some point to make a CT2-like card for STF/STE but everybody bashed him ... ). So for now I'll stick to the 68020 which gives me a better chance to actually finish this project then evaluate what's next. Rodolphe 2 Quote Link to comment Share on other sites More sharing options...
Tillek Posted July 21, 2015 Share Posted July 21, 2015 I'm very interested in this, and have 2 Mega STE's that I'd love to have a couple for! Depending on the price, I also have a few mega ST's! I also think using the 68020 is a good choice. Keeping the compatibility should be the priority, otherwise, it would not be of any real value to those of us who already have Falcons or TT's. Quote Link to comment Share on other sites More sharing options...
ParanoidLittleMan Posted July 21, 2015 Share Posted July 21, 2015 I don't think that patched TOS 3.06 is best idea for 68030 on some ST(E). Patched TOS 2.06 is much better, because video and other things. There is no need to patch so much CPU related things at all. You can even patch TOS 1.04 for 68030 . Compatibility with Falcon and TT will be low in any case - only things made for ST resolutions. SW using PMMU will crash on 68020 . Quote Link to comment Share on other sites More sharing options...
exxosuk Posted July 21, 2015 Share Posted July 21, 2015 I would really like to keep TOS104, but TOS206 seems a must to use 020 CPU. If TOS104 can be patched to work with 020, then I am all for that Quote Link to comment Share on other sites More sharing options...
ParanoidLittleMan Posted July 21, 2015 Share Posted July 21, 2015 I patched it already for 68030 . Quote Link to comment Share on other sites More sharing options...
exxosuk Posted July 21, 2015 Share Posted July 21, 2015 Backwards compatible with 68020 ? Also still fit in original TOS104 address space ? Quote Link to comment Share on other sites More sharing options...
ParanoidLittleMan Posted July 22, 2015 Share Posted July 22, 2015 All what you need to do is solving stackframe problem and adding proper initialization of CPU at start. However, the real hard part starts when you run diverse SW on it - then expect that some , aprox. 30% will have problems. And it is not possible to solve without changes in that SW self, except status register access in user mode problem, what is solvable in TOS self. The problems appear in code sensitive on stackframe size (8 instead 6 bytes) and pipeline error - code writing only few bytes ahead. Quote Link to comment Share on other sites More sharing options...
exxosuk Posted July 22, 2015 Share Posted July 22, 2015 Granted CPU will break some things, I think TOS206 breaks more things than the CPU though ? My STE with 020 TOS206 runs very little software, So I think keeping TOS104 would improve compatibility. Quote Link to comment Share on other sites More sharing options...
ParanoidLittleMan Posted July 22, 2015 Share Posted July 22, 2015 Yes, TOS 2.06 is not much compatible too. Problems are usually: more RAM occupied by TOS and Timer C dependance. Quote Link to comment Share on other sites More sharing options...
jvas Posted July 22, 2015 Share Posted July 22, 2015 Isn't KAOS TOS compatible with the 030? Quote Link to comment Share on other sites More sharing options...
ParanoidLittleMan Posted July 22, 2015 Share Posted July 22, 2015 Yes, Kaos TOS 1.42 is 68020/30 compatible. I checked. Don't know is translated in English . Quote Link to comment Share on other sites More sharing options...
jvas Posted July 23, 2015 Share Posted July 23, 2015 (edited) It seem, there is English version: http://www.atari-forum.com/viewtopic.php?t=11282 Edited July 23, 2015 by jvas Quote Link to comment Share on other sites More sharing options...
rpineau Posted July 26, 2015 Author Share Posted July 26, 2015 Quick update. I tested the card in the MegaSTE.. and it didn't explode. So at least that's good. But of course it doesn't work yet. I updated the status page with my findings. More test next weekend once I fix more of the CPLD code. I think there might be some error in the Motorola AN944. Rodolphe 1 Quote Link to comment Share on other sites More sharing options...
rpineau Posted August 2, 2015 Author Share Posted August 2, 2015 Quick update. I fixed some equation and I now see what looks like proper access to the TOS. The CPU even runs for 7 full seconds and then /AS stays up and nothing more seems to be happening (I need to add more probe to check for buss error and what not). I even saw what looks like a proper access to the keyboard ACIA by monitoring its CS1 pin and the VPA signal (see traces on the status page). I know my MegaSTE display the Atari logo after about 4 seconds.. so here 7 seconds with a black screen means something is not hapening and the CPU get stuc accessing something.. but what !!! /DTACK is tie to DSACK1 and pretty much follow /AS (/ST_AS). TOS access seem to be fine as I see a lot of them using the ROM /CE pin. Next step will be to make sure /UDS and /LDS are asserted as they should... may be there is a bad bus access and the CPU loops trying to get data from one of the component. If anybody has any idea.. let me know I have 2 more board that I might assemble if some people with a MegaSTE or STE want to help (TOS 2.06 required). I use Atmel WinCUPL with one of their ATF1504 (I have to move to the 1504 from the 1502.. not enough space ) and their USB JTAG cable. Rodolphe Quote Link to comment Share on other sites More sharing options...
rpineau Posted August 3, 2015 Author Share Posted August 3, 2015 So I was taking another look at a few of the 68020 board and docs (AN944, LUCAS, ...)... they use PAL16R4. I looked at the equation and basically copied them all in a single file, fix the names to remove unneeded pins and use internal pins of the CPLD. And as you all know.. so far it doesn't fully works... then I went back to the data-sheet of the PAL14R4 .. well well well .. look at that .. pins 14 to 17 are registered output ALWAYS .. which mean I need to recheck all my equation and based on which pin on the original PAL design they were on, make them registered (aka hey go through a D-Type flip-flop clocked by whichever clock was present on pin 1 of the GAL.. in my case the system clock). Sometimes it pays to pay attention to the component and not just the equations. Rodolphe Quote Link to comment Share on other sites More sharing options...
rustynutt Posted August 4, 2015 Share Posted August 4, 2015 Glad the MSTE is being put to good use Just don't put the AB project off too long! Quote Link to comment Share on other sites More sharing options...
rpineau Posted August 4, 2015 Author Share Posted August 4, 2015 The AB project is still on .. about to make new board and rebuild the Falcon, I should also get a Milan 040 to test on it Quote Link to comment Share on other sites More sharing options...
rpineau Posted August 9, 2015 Author Share Posted August 9, 2015 I did more work on this today. Some good news, I fixed DSACK1 and ACIA access (I think)... and some not so good news as it still doesn't work. There is definitive progress and you can see the update on the status page. Here is a quick picture of the test setup : Rodolphe Quote Link to comment Share on other sites More sharing options...
rpineau Posted August 10, 2015 Author Share Posted August 10, 2015 So I check all t he connection.. no short between the ST_BG pin and any other pins.. so no idea why it does what it does even if not connected to anything(see trace on the status page for the "/BG issue" ). For the MegaSTE schematics, the CPU /BG pin is directly connected to pin 9 of U2 (PAL 16R4, input 7). IT probably gets out through one of the output to U11 as the final /BG sent is coming out of that PAL on pin 19 (XCPUBG). SO there is NOTHING connected to this BG pin except for U2 pin 9 and that's an input !!! At this point I'm going to assemble a 2nd board to see if I get the same issue (I took one of the PCB I have and checked for shorts there to incase it could be a PCB manufacturing issue... nothing). Any idea ? Next time I connect the logic analyser to the MegaSTE I'll take trace of these pins with the 68000 in place before removing it to insert my board. I might also make a trace without any CPU to see what's going on. Rodolphe Quote Link to comment Share on other sites More sharing options...
Lynxpro Posted August 10, 2015 Share Posted August 10, 2015 (edited) Similarly, why wasn't the 68010 used that much? Was it problems with patching TOS 1.0 back then? Some users did upgrade to the 68010 but it gained a nasty reputation back then, circa 1986-1987'ish. Looking back, it kinda boggles my mind since a few Sega Genesis/Mega Drive owners have popped in a 68010 and seemed to have great results with almost all of the software with one of the exceptions being Shaq-Fu which almost nobody cares for... Edited August 10, 2015 by Lynxpro Quote Link to comment Share on other sites More sharing options...
ParanoidLittleMan Posted August 11, 2015 Share Posted August 11, 2015 Similarly, why wasn't the 68010 used that much? Was it problems with patching TOS 1.0 back then? Some users did upgrade to the 68010 but it gained a nasty reputation back then, circa 1986-1987'ish. Looking back, it kinda boggles my mind since a few Sega Genesis/Mega Drive owners have popped in a 68010 and seemed to have great results with almost all of the software with one of the exceptions being Shaq-Fu which almost nobody cares for... This may be off topic, talking about 68010 here. You can put it in Mega STE, and it works, because is supported by TOS 2.06, and pin layout is same as 68000. 68020 is another story . Why 68010 was not used much ? Looking specs, it says that fully 68000 compatible, virtual memory support, shorter instruction execution times. For some home computer in 1988 only latest is what could be real benefit. Virtual memory is useful only with hard disk. Fully compatible is not true - stackframe is not same. Don't know how faster it can be, likely not much, maybe 10-20% . And price was higher for sure. No wonder that manufacturers went on 32-bit CPUs - TT, Amiga 1200 , Intel 386 ... Quote Link to comment Share on other sites More sharing options...
Lynxpro Posted August 11, 2015 Share Posted August 11, 2015 This may be off topic, talking about 68010 here. You can put it in Mega STE, and it works, because is supported by TOS 2.06, and pin layout is same as 68000. 68020 is another story . Why 68010 was not used much ? Looking specs, it says that fully 68000 compatible, virtual memory support, shorter instruction execution times. For some home computer in 1988 only latest is what could be real benefit. Virtual memory is useful only with hard disk. Fully compatible is not true - stackframe is not same. Don't know how faster it can be, likely not much, maybe 10-20% . And price was higher for sure. No wonder that manufacturers went on 32-bit CPUs - TT, Amiga 1200 , Intel 386 ... Wait… TOS 2.06 natively supports which CPU, the 68010 or the 68020? Quote Link to comment Share on other sites More sharing options...
rpineau Posted August 11, 2015 Author Share Posted August 11, 2015 Both Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.