RAPIDUS ACCELERATOR

[Panther]

Good news regarding 1200XLs is that no adapter appears to be required at all... unless you have a VBXE fitted, and an XE-style VBXE at that. I found that perching Rapidus on top of about four sockets allowed it to clear the rear edge of the VBXE, but by then Rapidus was touching the back of the keyboard and the whole thing was none too elegant. So I made a small adapter which simply displaces the CPU socket about 1/8" further back, allowing it to clear the VBXE connector.

 

Very nice job on stuffing that 1200XL! I'm looking into my chances of stuffing all that into a 600XL...

[flashjazzcat]

Adapter version 2.0 complete and everything finally fits. I also replaced the 3-pin header with right-angle pins as Beetle suggested. This CPU adapter has the socket offset a full three pin rows back (c. 8mm), allowing the CPU (which became the new obstruction once the pin header was changed) to clear the back edge of the keyboard.

 

 

 

The lid fits very comfortably now and I have no worries about knocking or warping anything while typing.

 

As for operation: still getting to grips with things, but at least I haven't been plagued by instability so far. U1MB RTC appears OK, SIDE2 still works, internal IDEa (with custom APT BIOS) still works.

 

 

 

CPU speed is a little underwhelming but I'm assuming that's because the calibration test in the U1MB BIOS runs in ROM. I'm a little unclear as to whether the core loading issue associated with the Ultimate PBI BIOS is confined to DracOS or the stock OS: need to dig into my old emails a bit. Definitely something going on, though, since the machine does appear to hang from time to time with the U1MB PBI on.

Edited March 31, 2016 by flashjazzcat

[+Larry]

Good info, Jon!

 

"Adapter version 2.0 complete and everything finally fits. I also replaced the 3-pin header with right-angle pins as Beetle suggested. This CPU adapter has the socket offset a full three pin rows back (c. 8mm), allowing the CPU (which became the new obstruction once the pin header was changed) to clear the back edge of the keyboard."

 

For your adapter, do you just make a flux paste "path" and then run the solder from one solder tab to the next? I've never had much luck trying to make those "bridges," but then I never tried with flux.

 

Latest U1MB bios for hardware is 0.52? Default is the brown/sepia? (I find the gray/white is difficult to read.)

 

Thanks,

Larry

[drac030]

Core loading issue? If you mean the Rapidus core, then before it is loaded, the board is inactive, so if there is a software problem, it is confined to the ROMs which are located on the Atari motherboard.

 

PBI #0 must be completely free, there are no special requirements other than that in this respect.

[Smokeless Joe]

As for operation: still getting to grips with things, but at least I haven't been plagued by instability so far. U1MB RTC appears OK, SIDE2 still works, internal IDEa (with custom APT BIOS) still works.

So it's actually installed and working, at least a little? Do you have an install procedure for the 1200XL you could share? I'm still waiting for my Rapidus but I'd like to be prepared. Where did you make the connections? Thanks!

[flashjazzcat]

For your adapter, do you just make a flux paste "path" and then run the solder from one solder tab to the next?

The underside of the veroboard is striped with copper tracks, so I mounted the socket perpendicular to the tracks and made a cut down the middle. From then on it was just a case of soldering things up.

 

Latest U1MB bios for hardware is 0.52? Default is the brown/sepia? (I find the gray/white is difficult to read.)

The default is still black/white/grey, but I do configure things the way I like them here, and I like orange/brown. What you're looking at is the unreleased version 1.0, anyway, which is sitting on its hands waiting to be released while I figure out whether everything works properly with Rapidus...

 

Core loading issue? If you mean the Rapidus core, then before it is loaded, the board is inactive, so if there is a software problem, it is confined to the ROMs which are located on the Atari motherboard.

 

PBI #0 must be completely free, there are no special requirements other than that in this respect.

Well I really don't know and feel like I'm running around in circles with this issue. The problem (hanging when PBI BIOS enabled) was first reported months ago (via yourself, I think), no solution found, and then when I asked again I was told it was probably fixed. Last night I received an email from Michal (with Lotharek CC'd) saying the problem does in fact still exist:

 

...the only thing I have now would be the booting problem in SIDE+U1MB configuration. I mean the need of pressing the Reset button after the core was successfully loaded into fpga.

 

I've taken care to change the PBI device numbers, and I've made no speculations as the source of the issue since I'm not absolutely sure what exact scenarios I'm supposed to be testing. I have a Turbo Freezer here, though, and am ready to start investigations.

 

So it's actually installed and working, at least a little? Do you have an install procedure for the 1200XL you could share? I'm still waiting for my Rapidus but I'd like to be prepared. Where did you make the connections? Thanks!

Yes: I'm sure it works. I still have a new BIN and JED to install, but I want to take my time and not balls anything up. Of course I'll write up the installation procedure as soon as I get time.

 

EDIT: In the meantime, I can say that MPD was taken from the top of the pull-up resistor attached to MMU pin 14 (R87, I think: be careful to use the leg closest to the MMU), GND attached to S1 on the Ultimate 1MB (although you can attach it to GND as per the installation instructions if you don't want to control core loading from the U1MB BIOS), and EXTSEL was taken from the 74LS08 as per Bob Wooley's 1200XL PBI mod instructions. The EXTSEL mod can be done without the PBI, and is necessary for VBXE as well. In fact this 1200XL's EXTSEL pin is connected to Rapidus, VBXE, and the PBI connector at the back.

Edited March 31, 2016 by flashjazzcat

[TheMontezuma]

 

I guess the patching tool will not work with the 65816 OS.

 

 

Yes, it will not work with 65816 OS.

 

It may depend on how intelligent it is...

 

The patching tool detects only "well known" releases of the ATARI OSs and applies the timeout patch.

I was warned to distribute the patched ATARI OS versions due to copyright issues, that's why I created the patching tool...

 

Does the 65816 OS use the original ATARI SIO procedures?

If yes, the BT patch should be a minor thing.

[MEtalGuy66]

Got mine yesterday. Thanks, Lothar.

[drac030]

@montezuma: the SIO procedure is very similar, changing a timeout value should not be difficult. I do not guarantee however that its (the code's) location does not change over time, as I change some things there from time to time.

 

@fjc: I remember now. Whatever the cause is, it is not obvious, as I do not observe anything like that with IDE+ and it is (if I remember correctly) not reproducible on Altirra either. I think that someone with U1MB, Rapidus and a logic analyzer could simply see where the code gets stuck.

[flashjazzcat]

@fjc: I remember now. Whatever the cause is, it is not obvious, as I do not observe anything like that with IDE+ and it is (if I remember correctly) not reproducible on Altirra either. I think that someone with U1MB, Rapidus and a logic analyzer could simply see where the code gets stuck.

Well, it gets more interesting. Michal sent me the exact settings required to trigger the issue, but I can't currently reproduce the problem here. I'm using the latest ROM Lotharek sent me, but I'm still two JED file revisions out of date (will update that shortly). Using the default "Rapidus" profile, I can power-up or cold start SDX with the U1MB PBI BIOS present and working without any hangs and get a noticeably accelerated listing of the C: partition.

 

I hope this problem isn't intermittent or somehow machine-specific.

 

EDIT: One troubling thing I am noticing here is lots of unwanted reboots (and hangs) when pressing the Reset key. Sometimes the U1MB BIOS boots right from the splash screen, and sometimes it just reboots the OS. If I remove Rapidus, this issue disappears.

Edited March 31, 2016 by flashjazzcat

[pasiu]

CPU speed is a little underwhelming but I'm assuming that's because the calibration test in the U1MB BIOS runs in ROM. I'm a little unclear as to whether the core loading issue associated with the Ultimate PBI BIOS is confined to DracOS or the stock OS: need to dig into my old emails a bit. Definitely something going on, though, since the machine does appear to hang from time to time with the U1MB PBI on.

 

This is because you're operating in the Atari memory, not Fast RAM. Switch the RAM #0-#3 options to Fast reads, and then check CPU frequency in Ultimate Setup.

Displayed frequency at 2.38MHz can tell you one thing, that some internal operations of 65816 cpu were executed during the read or write cycle to Atari memory. This is becuse you had a CPU waitstates option set to OFF. If you switch it to ON, then you should get 1.77MHz.

 

EDIT: One troubling thing I am noticing here is lots of unwanted reboots (and hangs) when pressing the Reset key. Sometimes the U1MB BIOS boots right from the splash screen, and sometimes it just reboots the OS. If I remove Rapidus, this issue disappears.

 

Did you load anything to memory before you pressed the Reset key? Which settings did you have in Rapidus menu?

The way of how U1MB works make a lot of trouble to Rapidus. I was struggling with it for a long time, finally adding some extra logic only to handle this upgrade.

[flashjazzcat]

This is because you're operating in the Atari memory, not Fast RAM.

Yes - I figured that out eventually, thanks.

 

Did you load anything to memory before you pressed the Reset key? Which settings did you have in Rapidus menu?

The way of how U1MB works make a lot of trouble to Rapidus. I was struggling with it for a long time, finally adding some extra logic only to handle this upgrade.

Well, I finally suspected some conflict so emailed Konrad, who tells me there are hardware registers in two regions of $D1xx. I had assumed these would be obscured by U1MB IO RAM, but perhaps not and maybe this explains the problems I've been having (I eventually removed Rapidus from the 1200XL). If Rapidus does indeed react to writes to these areas even when the U1MB IORAM is mapped in under the hardware registers, then we certainly do have a problem. Of course I can probably code around it, but finding out about this stuff the same week I was about to release finalised Ultimate 1MB firmware is less than ideal.

 

If Rapidus has any other surprises up its sleeve which might affect Ultimate 1MB compatibility, I would certainly appreciate hearing about it now, if there's to be any hope of the new U1MB BIOS working well alongside Rapidus, and of the Rapidus finding its way back into my Atari.

[pasiu]

...U1MB IO RAM...

Yes, this is what I have in mind speaknig about the U1MB design and the way of working...

 

Rapidus is a PBI based device, so it has registers on $d1 page. However the access to those registers is possible after you write $01 to $d1ff. I have implemented full address decoding, so register under $d1ff adderss is sensitive only.

I will review my code to confirm that,

[flashjazzcat]

Ok - many thanks for you help.

IORAM is also written to when the configuration is unlocked (i.e. when BIOS has control, prior to OS entry), but I guess Rapidus registers are invisible then anyway. I'll check that $D1FF is cleared during BIOS activity.

Puzzlingly, the only thing which will force U1MB to perform a full reboot on reset is corruption of magic bytes or the setting of the internal coldflag override, neither of which appear to share addresses with Rapidus registers. Nevertheless, the 1200XL now reboots 100 per cent of the time on reset, regardless of settings, CPU type, etc.

 

EDIT: OK - I see a potential problem already. The BIOS resets $D1FF to 0 on entry, but not before magic bytes and the internal coldstart flag are written. I suppose it would be better to reset $D1FF before doing anything else at all.

Edited March 31, 2016 by flashjazzcat

[pasiu]

EDIT: OK - I see a potential problem already. The BIOS resets $D1FF to 0 on entry, but not before magic bytes and the internal coldstart flag are written. I suppose it would be better to reset $D1FF before doing anything else at all.

 

I'm not sure if this is a problem Jon. Pressing Reset key to enter the Ultimate setup clears the $d1ff register in Rapidus and makes the other registers invisible.

 

The other thing is that I'm not able to replicate such behavior (cold reboots) in my testing machines. I checked two XE computers, each of them have U1MB and VBXE installed and Rapidus of course. Unfortunately, to make U1MB cooperate with Rapidus in these Atari machines I had to solder some short piece of wire (5cm/2inch long) between GND signal of U1MB and the Atari motherboard.

 

The one of indicators that you have to do this mod is the resetting of U1MB RTC, and that is why I asked you to check is few posts above.

 

Can you do such extra connection?

 

Long wires of U1MB to Atari motherboard have quite high inductance and considering that Rapidus provides signals with much faster rise/fall times, we can get some signals ringing and false writes/reads at the end.

[MEtalGuy66]

I'm impressed. The 6502 compatibility is >90% even in "Rapidus" mode. Some games like Tomahawk and Soloflight are really ALOT better with this upgrade.

 

Alternate Reality seems faster/smoother than Wolf3D when moving through the city.

[flashjazzcat]

The one of indicators that you have to do this mod is the resetting of U1MB RTC, and that is why I asked you to check is few posts above.

 

Can you do such extra connection?

 

Yes, I can give this a try, although RTC and CONFIG do not get corrupted at any stage.

[+Larry]

I'm impressed. The 6502 compatibility is >90% even in "Rapidus" mode. Some games like Tomahawk and Soloflight are really ALOT better with this upgrade.

 

Alternate Reality seems faster/smoother than Wolf3D when moving through the city.

 

Does your MIO still work with Rapidus in there? Does it work in the faster Rapidus modes?

 

-Larry

[pasiu]

I'm also curious, because I've never tested Rapidus with MIO.

[jvas]

Should the cartridges work with rapidus?

Is there a version of flight simulator, that works in accelerated mode?

[flashjazzcat]

Can you do such extra connection?

Added the GND connection and the observable difference is that now the OS which appears when booting no longer flips randomly between that on the Rapidus ROM and the stock OS on the Ultimate. The reset button still spontaneously reboots the machine, however. The problem is slightly eased by connecting a SIDE cartridge (then the system reboots only about 50 per cent of the time), but things are highly unpredictable.

 

PBI issues (in 65C816 mode) are something I can't currently reproduce here, even when using a bit-perfect copy of the CF card apparently used when the problem was observed. I'm hesitant to release the final U1MB firmware until the existence of this issue is proven and its cause ascertained to be software rather than hardware. It seems unlikely that the reset issue has anything to do with the U1MB BIOS, meanwhile.

 

At least Impact finally recognized the FPGA when the board was cold, but it fails to do so when the Rapidus has warmed up. We might make the usual logical speculations regarding why, but I have no idea whether the problem is confined to the JTAG pins. Certainly the errant reset behaviour is present from cold powerup, although of course I realize this is a machine with a lot of upgrades in it. I might test the Rapidus in a 130XE next (also with U1MB and VBXE, but a lot less wiring mass) simply to verify board operation, although it'll be unfortunate if the Rapidus has to permanently vacate the 1200XL.

Edited April 1, 2016 by flashjazzcat

[flashjazzcat]

Moved to 130XE: seemed to work but then lost U1MB NVRAM content, then machine started hanging just before core loads. Changed CPU and it boots to self-test. Remembering advice, added U1MB wire to GND, but this didn't change anything.

 

I've run out of Dupont connectors otherwise I'd test in a stock machine.

[Marius]

Changed CPU and it boots to self-test.

Imagine... how fast you can do a selftest now with this Rapidus.

Edited April 1, 2016 by ProWizard

[drac030]

@fjc: how powerful is your power supply?

 

Here 2A seems sufficient to power a 320k Atari + Rapidus + IDE+2.0 + 2,5-inch HDD. But with the standard Atari power supply (1A or 1,5A), I would not be so sure.

[flashjazzcat]

2 Amps here as well.