Altirra 2.60 released

[morelenmir]

I would have considered a cold boot mandatory after a cart change or BASIC swap. Why is it a problem to do so?

Its not a problem FJC, but it is... somewhat user-unfriendly as with the "SDXImager" feature. This is especially the case here as when leaving the menu you get a fairly lengthy black-screen pause which I actually assumed was a cold-reboot. I guess that is the memory-zeroing going on that Phaeron mentioned. It must also lead to extra wear on the machine. The surge at power-up and power-down are where the maximum hardware failures occur in any electronics.

 

I think Drac030's solution is the very best one - store some kind of identifier in the RAM disk as to which programming language and OS was running when the data was written. If the current settings don't match on resumption then flush it. As he says, the CRC/SHA/whatever of the corresponding ROM's is probably the best way to do it. I imagine a similar problem would occur at changing the OS without off/on as well, although I haven't tried.

[fujidude]

Here is an even easier solution.... and it's already built in to the system:

 

If you put the /I switch after the BASIC command, it will ignore the BASIC.SAV file. Another option, is to clear the environment variable called $BASIC, and no file will be created at all upon returning to DOS from BASIC. One or the other of these solutions should fit any possible situation I should think. I would probably just use the /I switch if I was going to replace my BASIC with an assembler or whatever, or visa-versa.

[flashjazzcat]

Its not a problem FJC, but it is... somewhat user-unfriendly as with the "SDXImager" feature.

I still fail to see what's unfriendly about using SDXImager to edit CAR: and then a second tool to incorporate the image into the larger ROM, unless one is changing the contents of CAR: more than half a dozen times a day.

 

This is especially the case here as when leaving the menu you get a fairly lengthy black-screen pause which I actually assumed was a cold-reboot. I guess that is the memory-zeroing going on that Phaeron mentioned.

Unlikely, because as Phaeron mentioned, extended memory isn't zeroed out. Unless you mean pages 0, 2, 3, 4, and 5, which take no time at all to clear. There is a short boot delay to enable VBXE to power up prior to jumping straight into the BIOS. Again, surely the implication here isn't that this is some kind of inconvenience?

 

It must also lead to extra wear on the machine.

Clearing RAM? I'm lost.

 

Edit: right, you mean power cycling the machine. OK.

 

I think Drac030's solution is the very best one - store some kind of identifier in the RAM disk as to which programming language and OS was running when the data was written. If the current settings don't match on resumption then flush it. As he says, the CRC/SHA/whatever of the corresponding ROM's is probably the best way to do it. I imagine a similar problem would occur at changing the OS without off/on as well, although I haven't tried.

I never use the RAMdisk since we already have a hard disk which is faster, which I suppose is why I never encountered this issue.

Edited May 9, 2015 by flashjazzcat

[drac030]

I never use the RAMdisk since we already have a hard disk which is faster, which I suppose is why I never encountered this issue.

 

I do not quite get what is the controversy here. I have not experienced this issue either, but I think that it is a real one. It is true, as fujidude pointed out, that one can use /I, but one can also forget, especially those who keep the SAV files on hard disks.

 

Like: I played with BASIC three months ago, now I switch the internal cartridge to EASMD, and at this very moment I have no idea, that a 3-months-old BAS.SAV fle sits on the disk and will get loaded once I enter the EASMD. The next thing I see is a crash.

 

I think it is not a big deal to avoid that scenario by adding a simple check if the SAV file matches the active cartridge. I did not check that, so I may be wrong, but in fact SDX may already do that for external carts, just not for the internal BASIC (which is not supposed to be easily changeable).

 

Clearing all the RAM is obviously not only an overkill, but also an ineffective overkill (in case the SAV file is on a HDD).

 

PS. Any idea, why there are problems posting/answering posts from Internet Explorer?

Edited May 9, 2015 by drac030

[morelenmir]

I still fail to see what's unfriendly about using SDXImager to edit CAR: and then a second tool to incorporate the image into the larger ROM, unless one is changing the contents of CAR: more than half a dozen times a day.

 

I think we are going to have to agree to jovially disagree on that one FJC!!! However, as you say and we do agree, the "SDXImager"... lets call it a limitation... is far from critical.

 

 

Unlikely, because as Phaeron mentioned, extended memory isn't zeroed out. Unless you mean pages 0, 2, 3, 4, and 5, which take no time at all to clear. There is a short boot delay to enable VBXE to power up prior to jumping straight into the BIOS. Again, surely the implication here isn't that this is some kind of inconvenience?

 

No. No indeed. No inconvenience at all here. What I meant was I previously believed a cold reboot was going on during that black-screen interval. The BIOS Menu/"SIDELoader" work incredibly well. In fact for me they are the single feature which clinches my buying the "Ultimate1MB"\"SIDE2"\"VBXE" giant combo and using your software. In comparison the 'MaxFormat' solution with its dedicated flasher is unnecessary cumbersome and indeed could be considered financially exploitative.

 

 

Clearing RAM? I'm lost.

 

Edit: right, you mean power cycling the machine. OK.

 

Yep, On/off surge is where the majority of wear comes on to any electrical system and is especially damaging to microelectronics. I have a 2002 vintage desktop machine that I use as a Win2K3 member server on my very underutilized network and it has been off perhaps 6 times since I gave it that role. My actual desktop workstation is never turned off, ever by choice and only goes down if there is some problem with the electricity or I am altering the hardware. Now the terms 'Cold Reboot' and 'Warm Reboot' are used somewhat fluidly and I have usually read them meant to mean 'Cold Reboot'=Power cycle and 'Warm Reboot'='System Reset'/'PC Reset Button'. At least that is how I use them; simplistically 'Cold Reboot'=bad, 'Warm Reboot'=good/no harm done.

 

Well, it somehow never occurred to me in three years of developing for Ultimate 1MB to want to change the OS without a cold boot, but I suppose if it's deemed desirable and can be done, all well and good. Note that if the tactic employed is to clear extended RAM, this will result in further cold boot delays, depending on the strategy employed.

 

That's the whole point of beta testing and feedback isn't it? To encounter edge conditions and situations that don't occur to the programmer himself but seem every-day to another chap somewhere down the line. I agree that memory clearing is more of a bodge that a neat solution and I would only go for that were I the programmer responsible if there seemed no other practical way. Drac090 has the best and most logical approach with his checksum idea. At least it gets my vote.

[Kyle22]

OK, now that we're all thinking about the SDX Image tool for Windows, what are the possibilities of such a tool running under SDX that could edit the config files, and add / replace files on the CAR: device?

 

That would be a great companion for UFlash, giving the U1M / Incognito owner the ultimate in control over their machine.

 

Just one of those ideas that popped into my head as I was reading the thread...

[morelenmir]

OK, now that we're all thinking about the SDX Image tool for Windows, what are the possibilities of such a tool running under SDX that could edit the config files, and add / replace files on the CAR: device?

 

That would be a great companion for UFlash, giving the U1M / Incognito owner the ultimate in control over their machine.

 

Just one of those ideas that popped into my head as I was reading the thread...

 

Damn good idea Kyle22!!! Excellent, I agree totally.

 

I've always felt a bit frustrated that you cannot access and edit the user-area - wherever you feel inclined to try to use SDXImager - directly but must edit the ROM, the 'source' material as it were from which it is copied. Can "SDXImager" directly access the *.ATR flasher images or does the ROM have to be extracted from it to be worked on? I have never tried.

 

To be clear - I am not talking about the "Ultimate1MB" ROM here or any other whole-cartridge image, that issue has been talked to death and put to bed without supper. I mean the actual source ROM on the *.ATR's that will reflash an SDX-host device; the ones you get from the SDX site each time there is a new version released.

 

Update: ...and on experimenting I see SDXIMager will not operate on *.ATR's; it has to be pointed at the ROM image they contain.

Edited May 9, 2015 by morelenmir

[flashjazzcat]

I do not quite get what is the controversy here. I have not experienced this issue either, but I think that it is a real one.

You're right. My scepticism was borne of years of disuse of BASIC and RAMdisks. If the fix is inexpensive, it's sensible.

 

Clearing all the RAM is obviously not only an overkill, but also an ineffective overkill (in case the SAV file is on a HDD).

Well, quite so: on further thought the idea of (even optionally) erasing 1MB of RAM on cold boot does not seem appealing.

 

I think we are going to have to agree to jovially disagree on that one FJC!!! However, as you say and we do agree, the "SDXImager"... lets call it a limitation... is far from critical.

Decrying the SDX Imager's inability handle the compete Ultimate 1MB ROM would seem to me perfectly and arguably equivalent to complaining about The ROM Generator's inability to handle alterations to the SDX CAR: device; the very best of luck with that feature request.

 

Yep, On/off surge is where the majority of wear comes on to any electrical system and is especially damaging to microelectronics.

Apologies: it took me two readings of your post to understand what you actually meant. My bad.

 

That's the whole point of beta testing and feedback isn't it? To encounter edge conditions and situations that don't occur to the programmer himself but seem every-day to another chap somewhere down the line. I agree that memory clearing is more of a bodge that a neat solution and I would only go for that were I the programmer responsible if there seemed no other practical way. Drac090 has the best and most logical approach with his checksum idea. At least it gets my vote.

You're quoting material (presumably from an email notification) some three hours after I edited it. Please quote what's actually written.

[fujidude]

Like: I played with BASIC three months ago, now I switch the internal cartridge to EASMD, and at this very moment I have no idea, that a 3-months-old BAS.SAV fle sits on the disk and will get loaded once I enter the EASMD. The next thing I see is a crash.

 

But that's how you get reminded!

 

 

I think it is not a big deal to avoid that scenario by adding a simple check if the SAV file matches the active cartridge. I did not check that, so I may be wrong, but in fact SDX may already do that for external carts, just not for the internal BASIC (which is not supposed to be easily changeable).

 

I like that idea a lot actually. I just didn't want to give the impression that such a minor inconvenience was something I wanted to ask for a programming solution for. But, since you like the idea, I encourage it!

 

 

PS. Any idea, why there are problems posting/answering posts from Internet Explorer?

 

 

Sorry no. I long ago adopted FF (still like it best even after Chrome came out). I just got so annoyed with IE I could care less if I ever use it again. If you need it or want it though, I hope you find a solution.

Edited May 10, 2015 by fujidude

[fujidude]

BTW, how the heck is even a PBI based HDD faster than a RAM disk?

[morelenmir]

Decrying the SDX Imager's inability handle the compete Ultimate 1MB ROM would seem to me perfectly and arguably equivalent to complaining about The ROM Generator's inability to handle alterations to the SDX CAR: device; the very best of luck with that feature request.

 

Damnit!!! I thought I was on to a winner there! But seriously, if we as users don't have expectations then we can only ever receive programmes that fulfill their designer's goal and not our requirements... And at the end of the day which is the most important?

 

 

You're quoting material (presumably from an email notification) some three hours after I edited it. Please quote what's actually written.

Woah... Apologies of my own there FJC! I didn't realize you'd changed your reply. In which case... I still think testing is as much for these edge cases as confirming mainline functionality - perhaps more so!!!

Edited May 10, 2015 by morelenmir

[flashjazzcat]

OK, now that we're all thinking about the SDX Image tool for Windows, what are the possibilities of such a tool running under SDX that could edit the config files, and add / replace files on the CAR: device?

 

That would be a great companion for UFlash, giving the U1M / Incognito owner the ultimate in control over their machine.

 

Interesting idea, but quite difficult to implement. You'd have to queue up write requests otherwise every sector write to CAR: would trigger a JEDEC sector cache/erase. Best way to do it would be at the file level, so a file close would trigger a JEDEC sector cache/sector erase/sector write (or possibly multiples thereof).

[flashjazzcat]

...if we as users don't have expectations then we can only ever receive programmes that fulfill their designer's goal and not our requirements... And at the end of the day which is the most important.

 

As a developer for this very upgrade, I appreciate the importance of user feedback: perhaps to a fault. But although I have nothing to do with the development of SDXImager, I can empathise with the reception of "I want jam on it" feature requests. Perhaps the developer feels differently.

 

I still think testing is as much for these edge cases as confirming mainline functionality - perhaps more so!!!

Good testers are a rare thing, although on paper the only prerequisites are the time, inclination, and ability to break things, and the time, inclination and ability to describe the things broken, and using clear language. Edited May 10, 2015 by flashjazzcat

[morelenmir]

Interesting idea, but quite difficult to implement. You'd have to queue up write requests otherwise every sector write to CAR: would trigger a JEDEC sector cache/erase. Best way to do it would be at the file level, so a file close would trigger a JEDEC sector cache/sector erase/sector write (or possibly multiples thereof).

 

Ahhh... So basically the functionality is really butting up against the hardware capabilities there. Interesting. If it were a case of either/or then I think I'd stay with the way it currently is - its nice to have configuration files relatively 'safe' in the simulated ROM. A compromise - at least in so far as config.sys/autoexec.bat - would be to have 'merge' as the default. So you can still edit the setup from within SDX, but not run quite the same risk of completely overriding a working config.sys with a badly written one and losing all hard drive access and then not be able to remedy your mistake... Catch-22. I ran in to that problem when I was first experimenting with good old 'Kedit'. The only way around it was to go in to "FDisk" and remove the boot flag - and then re-edit. Obviously not as big a problem in Altirra but perhaps a real head-scratcher on actual hardware. Having the 'merge' at the discretion of the overriding file is asking for trouble.

 

Good testers are a rare thing, although on paper the only prerequisites are the time, inclination, and ability to break things, and the time, inclination and ability to talk the things broken, and using clear language.

 

Woah... I feel a bit of a sting there!!! Joking aside, the clarity is the most important aspect I would say - which is why I always try to be as clear as possible, sometimes too pedantically precise I fear. Without a user describing the exact problem you can literally spend several hours attempting to run down the issue and then realize it was their inability to use the programme all along that was causing the perceived 'problem'!!! I have been on both sides of that event all too many times! But equally... Sometimes that can also be at your feet as a programmer for not providing enough clear documentation. I know Phaeron frequently expresses surprise that anyone actually reads the help file for Altirra, but good, clear and up to date documentation is just as important as the software itself. For instance I have a Cisco firewall/router that I picked up for literally £2.99 from a carboot sale in Summer 2003 - yet I have never once got it work, despite how much I would like to because of the absolutely mind-boggling obtuseness of the telnet interface. Sometimes that is done deliberately to make sure only that company's specially trained and franchised workmen can attend to the machine or programme - and again I think Cisco is a perfect example of this.

[flashjazzcat]

You'll soon have the ability to turn off the boot drive but still access the HDD: no changes to SDX nor a writeable CAR: will be required.

 

And please, FFS sake let's have this discussion outside of the Altirra thread, before Avery gets justifiably pissed off with the both of us.

 

BTW, how the heck is even a PBI based HDD faster than a RAM disk?

Unbuffered IO.

Edited May 10, 2015 by flashjazzcat

[morelenmir]

And please, FFS sake let's have this discussion outside of the Altirra thread, before Avery gets justifiably pissed off with the both of us.

 

Fair enough FJC, fair enough.

[AtariGeezer]

Decrying the SDX Imager's inability handle the compete Ultimate 1MB ROM would seem to me perfectly and arguably equivalent to complaining about The ROM Generator's inability to handle alterations to the SDX CAR: device; the very best of luck with that feature request.

 

 

Damnit!!! I thought I was on to a winner there! But seriously, if we as users don't have expectations then we can only ever receive programmes that fulfill their designer's goal and not our requirements... And at the end of the day which is the most important?

There's No reason for "The ROM Generator" to have that functionality when the SDX Imager works

 

Otherwise, Good ideas are always welcome

 

So it looks like FJC is saying it would be too impossible for him to implement in uflash, too bad...

[Kyle22]

Jon, I did not mean an 'all in one tool', I thought of a separate, companion for UFlash to edit the SDX.rom image on a file level. The actual flashing would be done with UFlash after the user had made the changes to the SDX.rom file.

[drac030]

As about the cartridge checksums and stuff: I am looking at the code, and SDX already does that for all cartridges, incl. internal BASIC. Old memlo and cartridge checksum are the first three bytes of every SAV file, and the loading procedurę checks if these match the current configuration. So, I a very sorry, morelenmir, but it seems that in your case the problem is that two different cartridges happen to have the same checksum.

[drac030]

Correction: except when your machine has 1 MB RAMBO or 576k Compy Shop extension selected in the U1MB menu. Then the hashes are not calculated correctly and it is a bug in SDX.

[morelenmir]

Correction: except when your machine has 1 MB RAMBO or 576k Compy Shop extension selected in the U1MB menu. Then the hashes are not calculated correctly and it is a bug in SDX.

Its a real sneaky bug though isn't it?

 

As a matter of interest could you say why the number '3' is printed on 'shelling out' to "Assembler Editor"?

[drac030]

Honestly, I have no idea

[morelenmir]

Well... you can't say fairer than that!!!

 

Many thanks for taking the trouble to look in to this drac030.

[fujidude]

BASIC /I

 

is your friend.

[morelenmir]

Yup - I'll use that until the chaps at SDX correct drac030's hash-calculation bug.