Altirra 3.10 released

[Alfred]

There's something bugged with either the VHD or Black Box emulation. Altirra doesn't seem to always honor the MIO compatibility setting. For example, if it's on and I create some partitions in a VHD, and then I attach a new VHD and turn compatibility OFF, it seems like it leaves compatibility on. Then on a coldstart, the boot fails because the drive is now unreadable because now it honors the no compat flag. At least that's what it seems like. still trying to figure out what's going on. I think it's carrying the flags from the last VHD over, until a coldstart.

[phaeron]

There's something bugged with either the VHD or Black Box emulation. Altirra doesn't seem to always honor the MIO compatibility setting. For example, if it's on and I create some partitions in a VHD, and then I attach a new VHD and turn compatibility OFF, it seems like it leaves compatibility on. Then on a coldstart, the boot fails because the drive is now unreadable because now it honors the no compat flag. At least that's what it seems like. still trying to figure out what's going on. I think it's carrying the flags from the last VHD over, until a coldstart.

 

I'm not sure how this would be the case given that the MIO compatibility flag isn't a property of the drive or even the hardware, it's simply a DIP switch. The firmware is what interprets this as the MIO compatibility option and inverts data going to and from the drive. It isn't possible for this option to be carried along with the drive properties in the emulator. The firmware also re-reads this switch on each I/O operation, so you should see data get garbled as soon as it is flipped even before the reset.

 

What _does_ get cached by the firmware and only re-read on reset, though, is the drive table. Check whether the drive mappings and partition table are intact after the cold reset -- that may give a clue as to what's happening. What you're doing is essentially hot-swapping the SCSI drive, so it's not quite standard usage for the hardware.

[Alfred]

Yes, when the switch is flipped the data immediately changes. The drive table is changing as well. What first made me think it was an Altima issue was that when I looked at the file the geometry fields were all blank. If I deleted the three vid files and add them back, the geometry fields are populated and everything works.

 

Ill try formatting the drives again today and recoup everything and pay closer attention to the compat flag setting and see what happens.

[Alfred]

Ok, so the MIO compat flag is being ignored when it's changed. I create a VHD, format partitions, and load up the data, with compat ON. Works fine. Turn compat OFF, Shift-F5 to cold boot. Still works fine, and it should not, data should be scrambled. Close Altirra and then launch it. Now it gives boot error as data is unreadable. Don't see how it's a box error, emulation is providing the switch effect, must be something off with the switch itself.

[flashjazzcat]

Perhaps the BB firmware only reads the switch on a cold boot? Which is to say: perhaps the change will not take effect until you reboot the emulated BB.

Edited December 4, 2018 by flashjazzcat

[Alfred]

No, there's more wrong. The MIO compat switch setting is affecting other things. If Compat is OFF: 1) ultraspeed in BB is disabled. 2) all hdisk access is disabled (err 138 all VHD devices)

 

Setting a drive to Off in the disk drive listing disables that hard disk drive #. I dn't think the disk drive settings should override the PBI device, but I wouldn't say it's a bug, but it should be changed I think.

 

I don't get why having Compat off causes the VHD's to not work. Drives either return #138 or else FMTDIR reports that they are statusing as floppy drives, which has something to do with the Alt-D disk menu overriding drive settings. I tried setting Alt-D to Off for a given drive but that just disables the drive number completely.

 

So atm, the BB will only work if MIO compat is turned on. Which I hope can be fixed because BB reports partition size wrong if compat mode is on and >65536 sectors on partition. The real hardware does it wrong, so I'm assuming the emulation will as well.

[Alfred]

Perhaps the BB firmware only reads the switch on a cold boot? Which is to say: perhaps the change will not take effect until you reboot the emulated BB.

 

Well that could be, but the fact that the VHD devices cease to function if the switch is off renders it a bit moot. I guess I should go check a real BB and see what it does, but I think it polls the switch every time.

[phaeron]

You have too many things going on, try to reproduce with hard drive partitions that don't overlap the emulator's floppy drive emulation and make sure fast boot and D: SIO patch are disabled. There is a known problem with trying to mix the two on the same drive numbers and you will get weird issues if the emulator thinks it owns a Dn: drive number when the Black Box does as well. Normally you can work around this by enabling PBI disk mode in the emulator, but this doesn't work here because the Black Box can't coexist with other PBI devices, which means there is no clean way for the emulator to hook at the end of the priority chain.

 

I don't understand how to reconcile these two statements:

• Yes, when the switch is flipped the data immediately changes.
• I create a VHD, format partitions, and load up the data, with compat ON. Works fine. Turn compat OFF, Shift-F5 to cold boot. Still works fine, and it should not, data should be scrambled.

...it works, then you flip the switch and it doesn't, and you cold reset and it works again?

[Alfred]

Ok, well forget my earlier statements because I don't know exactly what I did. Today, I created new VHD files, copied data to them. The BB works, only if the compat flag is off. Flipping the switch only takes effect when Altirra is rebooted: it has no effect if the emulated machine is coldstarted (S-F5), although talking to Bob tonight he thinks the switch is checked for each i/o. With compat Off, the VHD devices don't respond, they return error 138. Sparta will not boot in ultraspeed either, but if you flip the switch to On and reboot Altirra then it works.

[flashjazzcat]

My mistake: I was away from the PC at the time and Shift-F5 cold resets the peripherals anyway.

[+Ripdubski]

@phaeron I found a bug in the save state routine. The tape position is either not saved, or not restored if it is saved.

[phaeron]

http://www.virtualdub.org/beta/Altirra-3.20-test7.zip

http://www.virtualdub.org/beta/Altirra-3.20-test7-src.zip

 

• Warp+ OS now saves NVRAM.
• AltirraOS 3.12: CBAUDL/H are now set by the cassette routines.
• Some rework on the build system to try to catch and report common setup problems.
• Fixed save state load errors when CPU set to 65C816.
• Tweaked the drag-and-drop overlay colors a bit.
• Fixed a crash in the debugger with deferred symbol loading.
• Added a new color preset for NTSC 800s with green/blue artifacting.

[Alfred]

Test 7 has the same issue as earlier. If the MIO compatibility switch is set to ON, then the Black Box disk functions don't work. It loads and saves the config fine, but all i/o operations to logical devices fail. The FMTDIR program reports that the hard disk partition is reporting that it's a floppy drive. Drives 1-3 are set in the BB to floppy and configed in the Alt-D menu. Drives 4-8 are set in the BB as hdisk partitions, so no drive number overlap. i/o to drives 1-3 are fine, 4-8 fail.

[phaeron]

Test 7 has the same issue as earlier. If the MIO compatibility switch is set to ON, then the Black Box disk functions don't work. It loads and saves the config fine, but all i/o operations to logical devices fail. The FMTDIR program reports that the hard disk partition is reporting that it's a floppy drive. Drives 1-3 are set in the BB to floppy and configed in the Alt-D menu. Drives 4-8 are set in the BB as hdisk partitions, so no drive number overlap. i/o to drives 1-3 are fine, 4-8 fail.

 

Test 7 doesn't have any changes to address your problem, because I can't reproduce it and you keep reporting contradictory information about what you are seeing. I cannot proceed on this any more without the following information:

• What version and CRC32 of Black Box firmware you are using. The CRC32 is reported in the settings for the specific firmware.
• The sector size and memory size settings for the Black Box, and all DIP switches that are set.
• Which DOS you are using, including specific version.
• Screenshots of the Black Box's Drive Configuration Page and Controller List Page.
• Which OS firmware and version you are using.
• Confirmation that the D: patch (Disk SIO) setting is off and SIO acceleration mode is set to SIOV Patch Only.
• Confirmation that drives 4-8 are set to Off in Disk Drives.
• Confirmation of no other devices besides the Black Box and the SCSI drive are in the Devices tree.

[Alfred]

Well, I have PBI only acceleration, not SIOV. I thought it was required for PBI devices.

 

CRC is A8953874 for BB 1.34 512 byte sectors, switches 1-4 set, 8K RAM

 

Sparta DOS 3.2Z (3.2D with internal ultraspeed disabled)

 

T-816 OS 3.11

 

Rtime8 and the Host are in the tree.

 

Edit: changing to SIOV didn't change anything, and setting 4-8 off disables the drives completely, err 138 now.

Edited December 10, 2018 by Alfred

[Alfred]

Actually I suppose it might be easiest to just zip up a system with the issue and send it it to you, so you can see exactly what's happening.

[phaeron]

Okay, again, you have too much other crap to diagnose problems with the Black Box. Disable the R-Time 8 and the H: device, and are you running a 65C816 system?? Use Atari XL/XE OS and a 6502, please.

 

And yes, you want PBI-based SIO acceleration turned off. The Black Box isn't designed to coexist with other PBI devices.

[Alfred]

Ok, a plain config. 6502, the BB, SIOV patch only, 6502, stock XL OS. Because drives 4-8 are off in the Disk Drive menu, they are disabled in the BB as well, error 138 if attempt to use them. Setting them to R/W produces an error in FMTDIR that the drive is not an HDISK. BB switches 1-4 are on, rest are off, 8K BB Ram.

 

If I flip the MIO compat switch to ON, then it all works.The Off or R/W setting in Disk Drives has no effect if MIO Compat is on.

[EddyFree]

Any chance of getting a quick "Peek/Poke" option, maybe under the Debug pull-down menu and with a hot-key? A peek would give both byte and word results for an entered memory location, and the poke would change the entered memory location to an entered value (and do a DPOKE if value is over 255 integer or specified $xxxx hex). A peek address specified as hex($ prefix) would yield hex results, otherwise integer. A poke address/value is integer unless specified as hex with $ prefix. I'm sure this would be easy to implement.

I can see a small window titled "Peek/Poke" pop up with two input lines, one labeled "Address", and the other labeled "Value". A push-down button underneath(like the update button on the Cheater) would be labeled "Peek/Poke". When pressed, if an entry has been made on the value line, it must be a POKE, if not, it's a Peek and the results(byte, word) will be printed on the value line. Obviously an address has to be entered or no action taken.

Currently, as far as I know, I have to drop into the Debugger or Cheater to modify a memory location. Having a quicker way sure would be nice, especially if I'm playing a game and know the memory location where number of lives is stored and such or I just feel like changing the color of the Atari screen real quick by poking location 710($2C6), etc.

[Mclaneinc]

As you say the debugger does these things, yes for an action replay type person like me (thankfully a disassembler person too) it seems a bit over kill to use the debugger but the point I'd say is that you can already do it in 2 places already (as you noted) which makes a 3rd way unlikely to happen. On a semi pedantic note, the naming would need o change, both peek and poke infer a drop back to Basic to enter them which is hardly ever possible on the Atari on a majority of games since basic is blocked out so it would need to be "Mem Change" or the like

 

As said, semi pedantic

 

Just my 2p's worth....Only Avery makes the choices, not us lot

[flashjazzcat]

I'd never even used the Cheater until now but using it to change the colour of the screen (using decimal values) took only five mouse clicks and five keystrokes (using the Tab key to advance to the value field) if I counted correctly, so being able to do the same thing with the same number of keystrokes and three mouse clicks seems to be on the redundant side.

Edited December 12, 2018 by flashjazzcat

[Wrathchild]

Was just about to suggest the same

[Heaven/TQA]

Isnt that poke feature something for xformer?

[EddyFree]

IMO, the Debugger is a powerful and complex tool. Dropping into it just to change a memory location or see the current value within one isn't the best use of it. And with the Cheater, you have to enter your memory locations and values and it constantly updates them in memory unless you uncheck them. Why would I want to continuously update say a screen color change?

As for the terminology "peek/poke", I really don't care what it's called as long as the functionality is there. I do think "peek/poke" sounds more "Atari-ish" than "Mem Change", which sounds more "Microsoft-ish" to me.

All I can say is I think it would be a very useful addition. We'll see.

[phaeron]

http://www.virtualdub.org/beta/Altirra-3.20-test8.zip

http://www.virtualdub.org/beta/Altirra-3.20-test8-src.zip

 

• Added Vista-style drag and drop support:
• Fixed AltirraOS version, wasn't actually bumped in the ROM image to 3.12.
• Fixed an issue with BlackBox switches not being set up properly on startup if set to switches 1-4.

 

@phaeron I found a bug in the save state routine. The tape position is either not saved, or not restored if it is saved.

 

This is one of many device settings that isn't saved in save states. It's not an expandable system, I need to rewrite it.

 

Ok, a plain config. 6502, the BB, SIOV patch only, 6502, stock XL OS. Because drives 4-8 are off in the Disk Drive menu, they are disabled in the BB as well, error 138 if attempt to use them. Setting them to R/W produces an error in FMTDIR that the drive is not an HDISK. BB switches 1-4 are on, rest are off, 8K BB Ram.

 

If I flip the MIO compat switch to ON, then it all works.The Off or R/W setting in Disk Drives has no effect if MIO Compat is on.

 

Sheesh... finally figured out what's going on. Still way too much crap in your setup, I got lost on the four drives until I figured out what was really going on.

 

First, the MIO compatibility option does nothing for 512 byte sectors. The 1.34 firmware ignores the option for that sector size. That's why the drives still read when you flipped the setting live.

 

What was really going on was that the Black Box PIA wasn't getting initialized properly if the saved setting for the DIP switches was the same as the default state ($0F). The broken switch state then caused the PBI firmware to disable itself for disk I/O operations.

 

Any chance of getting a quick "Peek/Poke" option, maybe under the Debug pull-down menu and with a hot-key? A peek would give both byte and word results for an entered memory location, and the poke would change the entered memory location to an entered value (and do a DPOKE if value is over 255 integer or specified $xxxx hex). A peek address specified as hex($ prefix) would yield hex results, otherwise integer. A poke address/value is integer unless specified as hex with $ prefix. I'm sure this would be easy to implement.

 

Sorry, no, I'm going to decline. This overlaps with the debugger and has too narrow of a use for the work it would entail.