Quick Question about VBXE

[Dmitry]

1 hour ago, drac030 said:

Onboard OS ROM will not be visible by 6502 in Classic mode. Nor onboard RAM.

 

 

So speaking of a machine with only Rapidus, to make this simple.  It cannot see the onboard OS rom.  So, where does the OS come from?

A 6502 OS is onboard the rapidus? or do I not understand something?

 

And will an atari with no onboard ram, os rom, or even onboard mmu, still work because the rapidus doesn't use it - I mean for my particular case that would be good, if that is the case.

 

 

[Dmitry]

19 minutes ago, Dmitry said:

Page 52, of u1mb: If you have the PBI BIOS enabled, you must set the ‘Hard Disk’ to disabled, otherwise external cartridges may be suppressed.

 

OK, one workaround I intended to try, which is PBI BIOS enabled - suppress Basic, but keep external cartridges - gonna try it now

 

 

I'm officially done.  Tried this, and first of all the cartridge only loaded part of the time, and then "MEMO PAD" starts coming out.  And the Rapidus wont' enter it's BIOS screen.

 

"MEMO PAD", huh?   I thought that was an Atari 400/800 thing.

 

I reset the u1mb to defaults, and Rapidus now enters its BIOS screen again.

 

The funny thing is, the machine is *stable* when it comes to accelerated mode, it's just I developed this desire to work in classic mode, which is like hitting my head against a brick wall.   It's kind of funny how it randomly glitches into Atari history here.

 

What next, will it force a game of pong?  haha...omg...well, I gotta take a break from this, later folks

[drac030]

26 minutes ago, Dmitry said:

So speaking of a machine with only Rapidus, to make this simple.  It cannot see the onboard OS rom.  So, where does the OS come from?

A 6502 OS is onboard the rapidus? or do I not understand something?

The 6502 ("Classic mode" or boot with the three-wire cable pulled off the connector) can only see the ROMs and RAMs which are installed on the Atar'is motherboard. Any additional ROM and RAM which Rapidus has "onboard" is only visible in the turbo mode.

 

So to run the Rapidus you ought to have an Atari with otherwise functioning OS ROM and MMU - these will be used initially to boot the Rapidus FPGA and start the 65C816. After that the Rapidus OS ROM can be used.

 

14 minutes ago, Dmitry said:

Tried this, and first of all the cartridge only loaded part of the time, and then "MEMO PAD" starts coming out.  And the Rapidus wont' enter it's BIOS screen.

You must have accidentally selected the OS slot with 400/800 OS programmed in. And yes, Rapidus will not boot under 400/800 OS - it is a PBI device (ID #0) and the PBI support only exists in XL OS.

 

[Dmitry]

23 minutes ago, drac030 said:

The 6502 ("Classic mode" or boot with the three-wire cable pulled off the connector) can only see the ROMs and RAMs which are installed on the Atar'is motherboard. Any additional ROM and RAM which Rapidus has "onboard" is only visible in the turbo mode.

 

So to run the Rapidus you ought to have an Atari with otherwise functioning OS ROM and MMU - these will be used initially to boot the Rapidus FPGA and start the 65C816. After that the Rapidus OS ROM can be used.

 

You must have accidentally selected the OS slot with 400/800 OS programmed in. And yes, Rapidus will not boot under 400/800 OS - it is a PBI device (ID #0) and the PBI support only exists in XL OS.

 

On the first part,  gotcha, I mistook a word you had used to mean something else - we are clear now.

 

on the second part - no way.  Uh huh.  I understand it must seem that way,  but I am not accidentally choosing anything.

 

If I am so hopeless incompetent as to be accidentally choosing random OS's all the time, within the space of minutes, while I am very carefully and intentionally not doing that - then I don't need a machine with a bunch of OS installed.

 

But it isn't me - I'm not doing it.

 

 

[drac030]

5 minutes ago, Dmitry said:

 I understand it must seem that way,  but I am not accidentally choosing anything.

So this must be the famous symptom of instability, where U1MB settings are incorrectly applied to the U1MB configuration register (or incorrectly read from the U1MB NV-RAM).

[Dmitry]

1 hour ago, drac030 said:

So this must be the famous symptom of instability, where U1MB settings are incorrectly applied to the U1MB configuration register (or incorrectly read from the U1MB NV-RAM).

 

 

 

I think so.  But, here is a video, showing it not working quite as expected to me.   I wanted to catch it.

Like I turned on the video camera the first time, and it showed Altirra OS - I was like, c'mon! I didn't choose that, but I also didn't capture the change on video, so I ultimately did find one glitch that seems to occur quite often, which is the processor in system information. and then not loading from cart is fairly common.

 

p.s. Also I tried in DOS hitting B run cartridge, and the message was no cartridge.

 

But when I go into Rapidus, and set it back to 65C816, and reset u1mb to defaults, I can then reboot the machine, it loads SDX, I type CAR, the cartridge loads, because that always works.

I can turn SDX off, and the cartridge loads, that always works.

 

It seems like wild crazy stuff, until I set it back to the mode that has worked these past 4 years, and that continues to work, just as it always has.    anyway, could be I've explored it as far as I can.

Edited December 9, 2020 by Dmitry

[drac030]

@Dmitry OOOOOoooooo, veery interesting.

 

Now, how things work when you select Classic mode and do Save/Exit:

 

1) the settings get saved to EEPROM

2) the menu program exits back to its caller (which is the PBI #0 device ROM)

3) this one validates the settings and resets them if they are invalid (they are reset to Classic mode in such a case)

4) now it is checked which processor has to be in charge

5) if it is 65C816, the PBI #0 code is exited normally or a jump to $e477 is done

6) but if it is 6502, the following procedure takes place:

a) cartridge CRC gets recalculated and saved to $03eb

b) interrupts lines from 65C816 are cut

c) 6502 is getting signals: HALT off, RDY on, RESET on

d) small delay takes place

e) 6502 is getting signals: RESET off

f) small delay again

g) 6502 start

h) STP = halt 65C816, tristate buses

 

From this point the 6502 takes charge, fetches the RESETVEC and proceeds with system start.

 

Now resetting the 6502 has probably unlocked the U1MB BIOS, so it is U1MB BIOS which should run now.

 

But when you enter the U1MB menu, it shows 65C816 running. Which means that inbetween another RESET signal took place, which woke the 65C816 and halted the 6502.

 

Since this does not happen on my system, I would guess that the source of that RESET signal must be U1MB.

 

And so this could explain the instability in the Classic mode, which is not really Classic mode, but weird mode with 65C816 on.

 

EDIT: well, no, nevermind. I definitely must go to sleep now: the "another RESET signal" is the one caused when U1MB is entered. So even if the Rapidus is not fully initialized then, exiting U1MB menu should clean things up and restore everything back to normal (i.e. to Classic mode in this case).

 

 

Edited December 9, 2020 by drac030

[candle]

1 hour ago, drac030 said:

Since this does not happen on my system, I would guess that the source of that RESET signal must be U1MB.

you would guess wrong - there is only one source of reset signal in Atari, and this is reset generator

if rapidus introduces another one - fine, but i just hope it doesn't override motherboard's generated one, just feeds additional one to cpu it is running

 

[+tf_hh]

On 12/7/2020 at 8:55 PM, drac030 said:

This is odd, because if we assume that U1MB BIOS has no influence, then after downgrading it things should not get better nor worse, but should remain about the same (unless there is an unforeseen factor here which is playing a role).

 

Well, after testing for hours in different settings I may have observed that the behaviour is changing during the first 4-5 minutes, when the system is started "cold" (powered off for one hour before for example). But this is not exactly reproduced.

 

Main conclusion: As long RESET key is untouched, all modes are running fine, but pressing RESET ends in different behaviors depending on U1MB yes/no, which Rapidus mode and also which 6502C CPU.

 

On 12/7/2020 at 8:55 PM, drac030 said:

Powering the machine up with this wire pulled off is not the same as starting it in the Classic mode. In the latter, the 65C816 is halted and disconnected from the buses, and FPGA is (should be) passive, because to my understanding it is only providing support for the 65C816 - and this one is, as I said, shut down.

 

This might be intendend, but I also have issues when this wire is left floating = Rapidus disabled. So "something" from the whole PCB must remain active in any way - maybe the CPLD you´ve mentioned below.

 

On 12/7/2020 at 8:55 PM, drac030 said:

But with the wire pulled off the situation is different: it is not only 65C816 halted and FPGA silent, but the board is not initialized at all. FPGA is not programmed, FastRAM, SD-RAM and FastROM is not accessible. So if there is a problem in this state, then it certainly does not come from a) Rapidus firmware, b) 65C816 CPU, c) FPGA. The only part remaining which can have some influence here is Rapidus CPLD - but its function is obscure for me, I cannot say what it exactly does and what signals go to it. It certainly has an ability to cut off IRQ/NMI signals coming from the motherboard from the CPU being in charge (i.e. either 65C816 or 6502 or both). Thus it perhaps also has the RESET signal connected, but this is my guess only.

 

Well., something only the developer can answer, as long no schematics at least are availible.

 

On 12/7/2020 at 8:55 PM, drac030 said:

I can see that I made some changes in the hardware detection routines: the BIOS makes memory sizing, so it has to detect the High RAM total and the banked SD-RAM; out of all the High RAM, how much FastRAM is there. The conventional Ext RAM. The VBXE, if it is present and where.

 

Is this information (VBXE present) shown anywhere? Didn´t find a place, even with updated BIOS and OS.

 

On 12/7/2020 at 8:55 PM, drac030 said:

Also, it tries to detect U1MB PBI BIOS (not U1MB itself, because I do not know how to detect that) at PBI IDs 2,4,6, and if found, sets U1MB compatibility bits in the Rapidus control registers [and here I can see that I do not have these bits documented in the register listing - must ask the designer then, what do they do, because now I do not remember]. This is a point where it could potentially make some improvement, but I must lookup the rest of the code to see what this does (after months I simply do not remember any of this).

 

What shall I say: I´m happy about every help or intention to help. More than just words is always a good way to solve issues ?

 

On 12/7/2020 at 8:55 PM, drac030 said:

I admit this. But the installation documentation is beyond my competence (it requires soldering, sockets etc.). I can write the Config guide, though, although I had an impression, that most of this must be self-explaining or is becoming clear after little experimentation, because nobody asked any questions.

 

As you see, also experienced users have questions. And, sad but true from my own projects experienced, some users didn´t dare to ask a question. Some expansions lay around for 1-2 years and then the user give up fast - among other things there´s no real documentation nor manual availible, just some incomplete installation instructions. I´m also pretty sure, several users didn´t know how you are and what have you done. They know "Lotharek" and nothing more.

 

On 12/7/2020 at 8:55 PM, drac030 said:

I have no power here, and can only speak for myself.

 

I know. Anyway: Thank you so far.

 

[+tf_hh]

9 hours ago, drac030 said:

The "R" core for VBXE supplies 256k RAM as standard Extension. As this is seen as a normal PORTB-controlled memory expansion, it should be visible in both modes just as an "actual" memory upgrade. The only problem will be that programs normally assume that PORTB-memory expansion and VBXE memory are separate entities and no part of that is shared. So in a computer with 320k RAM you normally have 256k Ext RAM plus 512k VBXE RAM amounting to the total of 768k in two expansions, while using the VBXE "R" core there is only 512k total in the expansion, out of what 256k is shared.

 

Yes, and that is the most important need for the ones who like U1MB _and_ Rapidus in one system - to have at least 512 KB extended memory. Nearly all other memory expansions need the used ANTIC slot, if you own VBXE. So there´s no easy and neat way to get 512 KB or 1 MB extended PORT-B memory plus VBXE and Rapidus.

 

[+tf_hh]

9 hours ago, drac030 said:

I am looking at the FPGA boot program (and no, it is not my code, so I have to analyze it to know what it is doing) and can see that it uses pages $8000, $8100, $8200 (and possibly more) for core decompressor. So it seems that at least the problems occurring when a 16k cartridge is inserted can be amounted to the design of the Rapidus boot code.

 

Interesting find! Seems to be the culprit why 16 KB modules won´t work and 8 KB mostly w/o problems. These decompression is done when the Rapidus "loading bar" appears with the core ID, right? So this only in a state where the memory can used completely. It should be possible to use $4000-$7FFF or lower memory areas then....

 

[+tf_hh]

Hi,

 

another issue - maybe somebody can cross check?

 

 

No U1MB installed. Rapidus enabled (Pin 1 of 3-pin connector tight to ground). Classic Mode is set. Boot any DOS you want, attached with the TurboFreezer 2011 (2nd Edition made by Panos). All functions of the Turbofreezer are disabled (except freezing of course, this can´t be disabled).

 

When pressing the "Freeze!" button, the Turbofreezer menu appears like normal.

 

Switch to Rapidus mode. Booting not possible, it sound like two D1: devices active, but they´re not. Same setup (one D1: disk via SIO2SD) like before. A "SYSTEM HALTED" message appears.

 

Setup the RAM#2 option as mentioned by @drac030, same issue. Switching bank to Classic mode - all fine.

 

I would expect problems when Freeze! button is hit using the 65C18, of course. But only by "existing" of the Turbofreezer? As I know, as long you didn´t switch on any of the functions with the switches at the Turbofreezer and don´t press the button, the whole Turbofreezer is absolute transparent to the system.

 

I´ve tested the 1st batch made by mega-hz, same problem, although in one of ten attempts a boot was possible. As assumed, the pressing of the Freeze! button does nothing (don´t wonder me).

 

Maybe somebody here owns both and can check. IMHO this one of the proofs for decoding/logic problems of the Rapidus FPGA/CPLD terms.

 

[+tf_hh]

7 hours ago, drac030 said:

@Dmitry OOOOOoooooo, veery interesting.

 

Forgot to mention, but this behavior I also got with the U1MB. FJC told me, it´s possible to switch ON the Rapidus if it was totally disabled before (at this time the correct CPU and speed is shown), then "65C816 21.12 MHz" ist displayed. But if you enable the classic mode OR switch off Rapidus in the U1MB BIOS, then these crude speed would be shown. You need to power-cycle before it´s normal.

 

7 hours ago, drac030 said:

[...]

b) interrupts lines from 65C816 are cut

c) 6502 is getting signals: HALT off, RDY on, RESET on

d) small delay takes place

e) 6502 is getting signals: RESET off

f) small delay again

g) 6502 start

h) STP = halt 65C816, tristate buses

 

From this point the 6502 takes charge, fetches the RESETVEC and proceeds with system start.

 

Thanks very much for this detailed infos. As more I think about, that in this part is somewhere something wrong. All issues start with the first RESET keypress after the machine is powered up. As long you didn´t perform a RESET, all is fine - not dependent which mode is active.

 

What I have seen today: During pressing RESET the addresslines (grabbed at the ANTIC) shown very wild spikes and are mostly with a width of less than 30 ns. The old, slow NMOS chips at the Atari mainboard won´t recognize such behavior. But modern, fast CPLDs like used on the U1MB and other expansions may be irritated. So MAYBE it´s not a software fault at the U1MB BIOS nor a logic fault by the U1MB CPLD, it´s a problem because Rapidus does something in Turbo-Speed to the Atari´s main parts during RESET phase. This would explain why systems without other CPLD/FPGA based expansions (directly connected to the buss!) works fine with Rapidus.

 

[candle]

i got the impression that cpu on rapidus is separated from the atari bus not only by fpga chip, but also by cpld chip that is doing all bus transactions with "slow" side, thus timings should be as they were

reset is asynchronous, so you can trigger it any time within clock cycle

what i also noticed during my ventures with 816 card i've made, reset was pulsed in 65xe i was using for development quite a few times

each time processor wouldd fetch reset vector and start executing code, then another reset would came and situation repeated - i don't know if this was a fault of this particular 65xe, or it is true in general

but maybe such behaviour would trigger some unwanted behaviour in cpld logic of bus arbiter

 

[drac030]

7 hours ago, candle said:

you would guess wrong - there is only one source of reset signal in Atari, and this is reset generator

I know. I was very tired (it was 6am already or so) and the most obvious soruce of that RESET signal did not occur to me immediately. I wrote this in later EDIT.

 

3 hours ago, tf_hh said:

Is this information (VBXE present) shown anywhere? Didn´t find a place, even with updated BIOS and OS.

No, the results of the tests are for internal use only. One should PEEK Rapidus control registers (from SDX prompt, for example) to see if related bits are set.

3 hours ago, tf_hh said:

These decompression is done when the Rapidus "loading bar" appears with the core ID, right? So this only in a state where the memory can used completely. It should be possible to use $4000-$7FFF or lower memory areas then....

I have to make consultation with the author. This code can be changed, assembled and flashed into the board, but the flashing functions are only available when the FPGA is up, and this code boots the FPGA. So one error... you know.

1 hour ago, tf_hh said:

I would expect problems when Freeze! button is hit using the 65C18, of course. But only by "existing" of the Turbofreezer? As I know, as long you didn´t switch on any of the functions with the switches at the Turbofreezer and don´t press the button, the whole Turbofreezer is absolute transparent to the system.

Except it probably adds some capaitance to the buses. Also, some devices built for the Atari (notably IDE+ revisions older than D) do not seem to tolerate well the multiplexed 65C816 bus, especially the fact that in the first phase of the cycle the data lines contain address. Maybe this is the case here.

 

Quote

crude speed

 

I guess this is the case when 65C816 is accessing exclusively the Atari motherboard's memory (ROM and RAM), but its internal operations are performed with no waitstates. This adds about 20-30% to the effective speed above the stock 1.77 MHz. But this should not occur when the machine is powered on with the three wire cable pulled off (Reset alone will not disable Rapidus after you pull the cable without powering the system down - by pulling the cable you only lose the access to the Config menu - and from what I understand, U1MB "Rapidus disable" function is effectively pulling the cable).

 

45 minutes ago, candle said:

but maybe such behaviour would trigger some unwanted behaviour in cpld logic of bus arbiter

Why this does not occur in all XEs containing Rapidus then? I would expect problems with multiple Resets on 800XL, where, IIRC, the RESET signal is kept on as long as one is holding the Reset key down.

Edited December 9, 2020 by drac030

[+tf_hh]

And another - I think final - video, before any of the HW guys get involved...

 

 

Because mostly Atari XE machines are used for Rapidus tests at the developer´s home, I remove the RESET circuit from the 800XL and built an 1:1 copy of the XE reset circuitry. For those who don´t know: There are differences. If you press and hold RESET at any XL machine, the RESET signal is also held low while the reset key is held. There´s a simple R/C link to have a small delay at power-up.

 

All XE machine have a real timer circuit using the NE555 standard chip. When you press and hold RESET at any XE system, the machine only sets RESET line for a small time low. then high again and machine shows screen again (or boots, or starts game, dos, whatever). Because this is technically a big difference, I built this into my test 800XL. Result: No difference ?

 

Again some tests without U1MB in the video. I focus on what´s happen if I press RESET. First test in the video shows an active Rapidus, set to highspeed mode. DOS loaded (again: Which DOS is not important) and COPY2000 V2.51. After the first keypress of RESET (see video 0:39) the first characters changed from the program´s menu screen. The V2.51 changed to V2>51.

 

2nd keypress: No news errors

3rd keypress: Watch the "O" in FORMAT. Or the new "0" before "ROM" in the 3rd line.

 

Later the ">" gets new pixels and so on. When one character is falsified, the all characters are damaged. This comes - for me - to the one and only conclusion, that the character font data is garbled. But wait - normally these are placed in ROM? I look into the code of COPY2000, it hasn´t an own font, it uses the standard in ROM found normally at $E000.

 

So in Rapidus-Mode the O.S. data seems to be copied in one of the (secured I think) RAM areas. But when a simple reset has an influence, there might be more. And failure is unpreventable.

 

From 1:33 (video) I test the same in Classic mode from Rapidus setup. After the first reset the issues starts... In classic mode the errors are more heavily. While in Rapidus mode the program remains mostly usable, in Classic mode after the 1st or 2nd keypress of RESET not only the menu is garbage, you can´t also start a copy.

 

 

 

 

 

[drac030]

5 minutes ago, tf_hh said:

So in Rapidus-Mode the O.S. data seems to be copied in one of the (secured I think) RAM areas.

Well, no. The font data is fetched by ANTIC from the "normal" place in the ROM or RAM placed on the Atari's motherboard. I.e. it comes from the standard OS in this case.

[+Stephen]

Forgive me if I am talking out my backside.  But was there not a previous issue on some machines (I think 1200XL even) where a 100pF capacitor was added across the reset pins on U1MB to stabilize them?  Could a similar issue be happening here - spurious signal, noise, etc. on the reset line?

[drac030]

5 hours ago, tf_hh said:

As you see, also experienced users have questions.

Forgot to reply to this. I can answer questions related to the operation of the firmware (= ROM software), and how the boot/reset process works from the point of view of the firmware and external software, because generally the software is my province. Also I can explain something on how I think the hardware generally works, but here I would prefer a hw guy to take charge ("capacitor", or "falling edge" is in fact Chinese to me - I generally can tell the difference between a resistor an a transistor by the number of legs and that is all).

 

It would be useful then if potential/actual users could first ask questions on the matters they do not understand. Best in the form "What is..." or "What does this/that do", or "Why when I do that, happens this". It would greatly help me to see what matter is difficult and what not.

Edited December 9, 2020 by drac030

[Dmitry]

OK, what this video is about is showing a short sequence of events that results in a problem.

 

I titled it "Cold Boot to Basic", but where this u1mb initiated reboot is considered "cold" or not, I don't know.  My issues begain with desiring to use "classic" with fujinet. FujiNet has a program where you set an ATR - and Fujinet reboots the machine - that results in problems.  So, it isn't merely when I touch the reset key, but other restarts.

 

As far as I know - which is very little, hitting the reset button on the machine pulls the /reset line on the CPU.  I still don't understand how this setup can have the wrong CPU and yet successfully pull the /reset line.

 

Anyway, I'm backing up now, not going down the path of workarounds, but now, just trying to be more specific here.  If you have a cartridge in the port, it shouldn't boot to basic.

I don't want to workaround that, just pinpoint where the problem occurs.   In this video, I power  off many times - the CPU is wrong as listed in U1MB, both the speed and cpu type.

 

Powering off doesn't correct that problem, it is pretty much wrong 95% of the time. Occasionally it looks correct, but I haven't figured out how to regenerate a correct result.

 

One thing I'm trying to add here, is I don't necessarily have to have a problem from recently touching the reset key on the Atari, I seem to be able to get a problem when what appears to me what is happening is a software initiated reboot.

 

If that is explainable - I don't know.    I am going to pull the U1MB from this system.   Even if it isn't the problem, it is what is delivering up a host of OS's and Basics internal to the machine, and I never wanted that - at all, so that will be one improvement by pulling it.  And secondly, it just simplifies this troubleshooting process to have it removed, imho.

 

So any hardware gurus that want the job, pm me.

 

 

 

 

 

 

[Dmitry]

Btw, I have now also removed the Sio2SD from the equation and have replaced it with an Atari 1050 drive, but it makes no difference.

 

I made several other videos of the problem, but each time that I had hoped to reproduce the problem reliably, I couldn't, therefore I don't find the videos interesting any longer.

 

I'm a professional programmer, that's my day job.  I work in healthcare analytics.  If I don't have the skills to operate an Atari, I accept my fate   

 

But in my view, I have a pretty good handle on writing code for the Atari in assembler,, although only tackling display list interrupts, reading from the joystick, antic operations, and stuff like that, obviously still to learn is XIO type commands and early startup - and I really will learn on as needed basis.

 

As far as "understanding" why I have to hit multiple key combinations to switch the machine on and just launch a program from disk, I'm not going to understand it.  It's also known as being stubborn.  I don't wanna do it, I'm not gonna do it.

 

Edit:  p.s. this message isn't addressed to any person - I'm just venting.   So, thanks again to everyone for looking into the state of things.  I've kind of gone into this troubleshooting mode since yesterday...and now I'm trying hard to reset the human here, and go into another mode - gotta get back to coding, lol

 

 

 

 

 

Edited December 9, 2020 by Dmitry

[drac030]

On 12/9/2020 at 12:34 PM, tf_hh said:

Interesting find! Seems to be the culprit why 16 KB modules won´t work and 8 KB mostly w/o problems. These decompression is done when the Rapidus "loading bar" appears with the core ID, right? So this only in a state where the memory can used completely. It should be possible to use $4000-$7FFF or lower memory areas then....

It seems that this problem has already been solved, here is the thread:

 

 

I completely did not remember that one. Anyways, the author has posted there the revised version of the booting code.

[drac030]

@tf_hh Re Rapidus and reset issues, I recalled something. Four years ago there was this topic here:

 

 

Watch the film in the first post: this is 1200XL, it has some RAM extension they mention ("this is 1 mega of memory") which looks like U1MB, Rapidus and VBXE. In the process of demonstrating the internals they inadvertedly press Reset - the LED on the Rapidus board blinks then, and later they have to reload the program they had already loaded before.

 

In any case, there are no visible stability issues during that. So maybe it would be worth consulting @Beetle if he had any issues and how he solved them.

[+tf_hh]

On 2/27/2021 at 2:05 AM, drac030 said:

@tf_hh Re Rapidus and reset issues, I recalled something. Four years ago there was this topic here:

 

Watch the film in the first post: this is 1200XL, it has some RAM extension they mention ("this is 1 mega of memory") which looks like U1MB, Rapidus and VBXE. In the process of demonstrating the internals they inadvertedly press Reset - the LED on the Rapidus board blinks then, and later they have to reload the program they had already loaded before.

 

Well, thanks for this (I´ve found it before). Under the bottom line my decision is based on the behaviour of the involved people. You were the ONLY one willing to help and support. The hardware designers doesn´t care anything about. The seller makes useless tests and doesnt´spend only 10 minutes to understand what´s going on because he hasn´t time. Ok. Accepted.

 

I have a high quality standard in all things I do and especially things I do for my customers. As long I didn´t stand with 100% behind any product, I didn´t sell or install it. So easy. As long I didn´t see communications, support and the real will to solve some of the rare, but reproducible bugs, Rapidus is a No-Go for me and I didn´t install it anymore. End of story.

 

[drac030]

Note that I am not the reseller nor the designer. Their e-mail addresses are, I think, either known or easy to find, so I am sort-of unsure what is the use of directing the complaints at me. I am not their boss nor their father and not even their mother-in-law.

 

12 hours ago, tf_hh said:

the real will to solve some of the rare, but reproducible bugs

If they are reproducible, please tell me, how do I reproduce them.

 

For now, if what you call "bugs" occur on your system, but not on mine, Beetle's (?) or several others, then it seems to me as most likely that the ultimate cause of any bad behaviour must lie in the computer itself - in some of them, that is.

 

So the question is: what I have to break in my 65XE to reproduce the bad behaviour.

 

Thanks in advance.