New (alt) BIOS for Ultimate 1MB/Incognito

[foft]

Hi,

 

Finally installed my Incognito and have a beginners question.

 

It mostly seems to be working. For some reason internal basic is broken in XL/XE and 800 mode I think (I get self test or memo pad).

 

I thought I'd try the latest BIOS to see if it behaved better with that. So I downloaded it from here Incognito firmware package (ZIP) I set it to XL/XE, 1MB, spartados on and then loaded xlflash.xex from aspeqt using the built in spartados. It did not detect the hardware so I selected incognito, then it gave me a blank window with just OK. I pick that and I get a corrupt gr.0 screen of graphics characters, including the text 'Flash code based on'.

 

I checked the troubleshooting in the manual and am non the wiser. Any hints, tips or links to relevant threads greatly appreciated. Otherwise I'll need to use my brain, but its too late right now here for that :-)

 

Mark

 

Edit: Errr, just reseated the board + pushed wires in. Now Basic works, trying to flash!

 

Edit2: Its all fine now:-) Sorry!! + Many thanks for the new BIOS:-)

Edited August 17, 2016 by foft

[Roydea6]

Just wonder if uflash is software compatible with Incognito Colleen mode with OSB rom.. Before I change any OS slots for Colleen mode..

[flashjazzcat]

Never tried it, and doubt I will while my programmer is U/S. You can flash everything in XL/XE mode, however.

[fujidude]

Never tried it, and doubt I will while my programmer is U/S. You can flash everything in XL/XE mode, however.

 

U/S meaning unsupported? I remember you saying no Windows 10 drivers I think? If the programmer has a USB or even standard serial interface, you could set up VirtualBox, run a driver compatible version of Windows inside it, and configure it to have the appropriate USB or serial device given to the VM.

Edited August 22, 2016 by fujidude

[flashjazzcat]

Yep. I meant unserviceable, but the result is the same. The issue isn't a lack of Windows 10 drivers, but the fact the driver which worked perfectly well under Windows 10 for the past twelve months was irrevocably nuked by the Anniversary update, presumably for no good reason other than to make me purchase an alternative from a manufacturer who'd paid MS for up to date driver certification.

 

Been fiddling with Ubuntu today for testing purposes (pointless exercise, but that's not the OS's fault) and considering spending more time with Linux. That doesn't solve the programmer issue, but virtualization is a valid suggestion, especially since I rarely use the programmer. I might just dual boot Windows 7 on the main PC, though.

[fujidude]

Ubuntu is great, but it's derivative Linux Mint is what I give my top recommendation for. I previously used Ubuntu though and do like it.

[flashjazzcat]

I've noticed your Mint advocacy, and it's a variant I'd already tried and liked. This time I was using Lubuntu on a low-powered 32-bit netbook and it's great too. I don't need a Windows-like desktop, though (I prefer Mac OS), so Ubuntu will probably be the next desktop experiment.

[fujidude]

I've noticed your Mint advocacy,

 

Has it been that obvious?

[flashjazzcat]

Quick question regarding features in the forthcoming update. ATR mounting in the PBI BIOS received a complete re-write after I realised the original implementation was unnecessarily verbose and repetitive. This freed up 500 or so bytes of code space which I immediately filled with a CIO "Z:" clock handler aimed at SpartaDOS 3.x users. But upon further thought, I wondered if the space might be put to better use by properly implementing the ability to specify a 24-bit SIO buffer address for sector transfers when using a 65C816 CPU. This capability is elegantly implemented by the XDCB specification written by Drac030. The PBI BIOS already implements the extended (up to 32-bit) sector addressing, but so far not sector transfer to and from any but the base 64KB bank.

 

The decision is somewhat complicated by the Rapidus compatibility issues which have not yet been resolved. I am reluctant to provide support for the Rapidus when the PBI BIOS is still plagued by issues on Rapidus equipped machines (and this is not a stability or overheating issue, but apparently some address decoding matter, from what I can gather). Hope that the issues will eventually be addressed has not completely vanished (from my point of view, at least), although I have received no word that a fix is even being investigated.

 

Anyway: if anyone has a (constructive) opinion one way or the other, please let me know.

[Kyle22]

Remember, it's not only Rapidus owners who have 816s.

[Roydea6]

CIO Z: clock sound good, but why specify SpartaDos 3.x users.

[flashjazzcat]

Remember, it's not only Rapidus owners who have 816s.

 

Very true. I understand your Incognito setup is running nicely. Rapidus is the only means I have of testing a 65C816, though, and until such time as I can see the hardware and software working together, I can't really develop anything and describe it as "working".

 

CIO Z: clock sound good, but why specify SpartaDos 3.x users.

 

I guess SD 3.x springs to mind since SDX is equipped with kernel drivers for the same purpose, and few other DOSes bother with the clock at all. But outside of the file system, it works with any DOS you like.

[Kyle22]

. . .I guess SD 3.x springs to mind since SDX is equipped with kernel drivers for the same purpose, and few other DOSes bother with the clock at all. But outside of the file system, it works with any DOS you like.

 

That would make it easy to make a talking S.A.M. alarm clock.

[flashjazzcat]

Note the same facility is available with the SD 3.x RTime-8 driver, SDX Z: driver, IDE Plus 2.0 Z.COM, etc. Hence the uncertainty as to whether it's the best possible use of ROM space.

[lemiel]

Only if easy exchangeable. Like plugins for eg. turning on and off stereo

[+mytek]

This might be a tad bit off topic, but since you seem to be in the mood to make some significant changes I thought I'd toss in another feature that would be great to have if at all possible.

 

It has to do with using the SIDE Loader. So in essence what I think would be really nice to have would be some sort of pointer as to where you are in the menu hierarchy restored upon reentry. So for instance lets say I've drilled down to GAMES> EXECUTABLES>P>PA and launched PAC-MAN (V1). Then I get tired of that particular version and want to try PAC-MAN (V2) instead. When I go back to the SIDE menu I'm put back at the very top, having to once again drill down to that same directory I originally started at. It would be much nicer if I were automatically returned to the directory I was in before. Is there some way that this could be implemented, or does the option to do this already exist and I'm missing it?

 

- Michael

Edited August 26, 2016 by mytekcontrols

[flashjazzcat]

Only if easy exchangeable. Like plugins for eg. turning on and off stereo

That's the approach I prefer too, but I did not yet extend the plug-in architecture of the main BIOS to the PBI BIOS. I will perhaps think about that, although it may become ridiculously complicated. With the main BIOS (as described in the tech docs), one may create a plug-in module of up to 1KB in size which defines extra items in any of the eight menus, storing configuration bits in the two bytes of NVRAM dedicated to BIOS extensions.

 

With the PBI BIOS, there are severe bank-switching, code space and performance restrictions: all the code - including the integral read-only FAT file system for ATR mounting and the high-speed SIO driver - is crammed into four 2KB banks. And yet we now have 500 or so bytes free.

 

If the Rapidus issue will be resolved, I'd be inclined to opt for the high RAM sector transfers, but we'll see. I appreciate the opinions.

 

On the subject of plug-ins: the next version of UFLASH is capable of flashing the entire 64KB firmware chunk (including main BIOS, loader and PBI - PBI being 32KB long, 24KB of which is unaddressable padding) as a single entity, so the the issue of matching up two separate plug-ins would be resolved there. Unfortunately this doesn't work as easily with Incognito (since firmware is not contiguous on the flash ROM), which anyway lacks the plug-ins (didn't seem much point since there are no AUX signal headers, and besides there's no room, since the Self-Test ROM cannot be mapped to $5xxx when the config is unlocked, whereas it can under U1MB).

 

This might be a tad bit off topic, but since you seem to be in the mood to make some significant changes I thought I'd toss in another feature that would be great to have if at all possible.

Heh. I'm in the mood to get this signed off and done and resume work on the GOS. But this has been an interesting project, and I guess we're getting close to completion now.

 

It has to do with using the SIDE Loader. So in essence what I think would be really nice to have would be some sort of pointer as to where you are in the menu hierarchy restored upon reentry. So for instance lets say I've drilled down to GAMES> EXECUTABLES>P>PA and launched PAC-MAN (V1). Then I get tired of that particular version and want to try PAC-MAN (V2) instead. When I go back to the SIDE menu I'm put back at the very top, having to once again drill down to that same directory I originally started at. It would be much nicer if I were automatically returned to the directory I was in before. Is there some way that this could be implemented, or does the option to do this already exist and I'm missing it?

It's a good suggestion, and possibly doable - but it's risky. You'll probably have noticed that the last accessed partition on the card (whether it be the APT or any of the FATs) becomes the default until the card is swapped or the partition structure changes. This appears reliable and is implemented by creating a 16-bit CRC of the entire MBR partition table and storing it in NVRAM. The CRC is rebuilt when the partition table is next scanned and compared with the NVRAM copy. If it's different, we assume it's either a different card or some changes were made to the partition table, thereby invalidating the default entry.

 

Sure we could also stash the cluster number of the last accessed directory, but we'd need some kind of change detection mechanism for that too in order to ensure that the stored cluster number still points to a directory at all (since the user could have issued an RMDIR or format command on the PC since the card was last accessed on the Atari).

 

In addition, I think we'd then need to display the path at the top of the menu, since the assumption that the loader starts up in the root directory of the last accessed partition would no longer be valid. I was going to put that in last time but actually ran out of code space...

 

As far as navigation goes: I think the last loader update I released had the "Group folders" option. If you turn that off, all the folders - instead of being grouped at the front and un-searchable - appear in their alpha positions mixed in with the files. This makes them searchable, so if you have access to the keyboard, using your example (and depending on other entries in the directory structure), you might be able to get to GAMES>EXECUTABLES>P>PA by typing:

 

G, <Enter>, E, <Enter>, P, <Enter>, P, <Enter>

 

Obviously you may need to type two or more characters to disambiguate the selection: for instance, if you wanted the "PE" folder, you'd type PE <Enter> at the final step.

Edited August 26, 2016 by flashjazzcat

[fujidude]

Since we were solicited, I want to put my 2 cents (or pence is it?) on this. Don't forget to leave enough room for bug fixes, should they require more address space than the code they fix.

[flashjazzcat]

Don't forget to leave enough room for bug fixes, should they require more address space than the code they fix.

 

Yes: no worries. There were still about sixty bytes free even with the Z: handler. Of course, when we run out of space for fixes and new features, we just shrink existing code. The XEX loader suggests this is a process which can go on indefinitely.

[flashjazzcat]

Yep. I meant unserviceable, but the result is the same. The issue isn't a lack of Windows 10 drivers, but the fact the driver which worked perfectly well under Windows 10 for the past twelve months was irrevocably nuked by the Anniversary update, presumably for no good reason other than to make me purchase an alternative from a manufacturer who'd paid MS for up to date driver certification.

 

Been fiddling with Ubuntu today for testing purposes (pointless exercise, but that's not the OS's fault) and considering spending more time with Linux. That doesn't solve the programmer issue, but virtualization is a valid suggestion, especially since I rarely use the programmer. I might just dual boot Windows 7 on the main PC, though.

 

My reluctant apologies to Windows 10. The EEPROM programmer driver installs just fine on a fresh install of the Anniversary update on a Core i3 laptop I'm fixing, so looks like my desktop simply threw a wobbler and lied to me about the ZLG USB driver being blocked. I merely have to reinstall the entire OS plus all my applications over the weekend and all should be well. Oh joy...

[fujidude]

 

My reluctant apologies to Windows 10. The EEPROM programmer driver installs just fine on a fresh install of the Anniversary update on a Core i3 laptop I'm fixing, so looks like my desktop simply threw a wobbler and lied to me about the ZLG USB driver being blocked. I merely have to reinstall the entire OS plus all my applications over the weekend and all should be well. Oh joy...

 

But it still was working on the machine pre Anniversary update, and failed post update. Granted, that in and of itself is nowhere near as bad permanent incompatability, but it's still annoying.

 

Anyway, if by flatten you mean clean install... I have a suggestion to try 1st which is quicker. You may have already thought of this but...

1. make sure programmer is not plugged into computer
2. use the device manager to completely remove the device from the tree
3. install the driver again
4. plug in the programmer
5. see what happens

If the driver installation prompts for the device to be plugged in as part of the driver install, do step 4 then with step 3.

Edited August 26, 2016 by fujidude

[flashjazzcat]

Thanks, but I tried every imaginable method of getting that driver installed and it now silently fails. I even manually cleaned all trace of it from system32 and syswow64 and the driver repository, but it didn't help. Heck... I didn't clean install since last October so it's probably overdue.

[fujidude]

Thanks, but I tried every imaginable method of getting that driver installed and it now silently fails. I even manually cleaned all trace of it from system32 and syswow64 and the driver repository, but it didn't help. Heck... I didn't clean install since last October so it's probably overdue.

 

Bugger all.

[morelenmir]

Thanks, but I tried every imaginable method of getting that driver installed and it now silently fails. I even manually cleaned all trace of it from system32 and syswow64 and the driver repository, but it didn't help. Heck... I didn't clean install since last October so it's probably overdue.

 

This reminds me strongly of all the trouble I have had with the FTDI drivers for the SIO2PC-USB device.

 

On that note I can honestly say I will never upgrade to a Microsoft OS later than Windows 7. I highly, highly doubt they will ever make the retrenchment to user control and stability which they did in the aftermath of the Vista farrago and then promptly forgot about in time for Win8 and WIn10. Despite the fact the latter was meant to be the big apology to us all for the 'Metrosexual' former!!! There are so many problems with Microsoft's corporate arrogance - best summed up by Don Mattrick's career suicide over 'if you don't like always-on internet and big brother watching/listening/reading lips through the Kinnect then stick with the 360'... Which was good of him - and I did. The last we heard of that pratt was when his golden parachute from MS landed him on the slippery pole down to Zinga who are currently circling the drain as well. I wonder if those fact are connected? In fact, now I think of it hasn't he bailed on them as well??? Yet, yet when MS tries hard not to control our lives and just focus on quality they can produce absolutely unbeatable material. It is that which makes the company so frustrating in my opinion.

 

Anyway - that is clearly off-topic. My only real suggestion is actually a question and ultimately a rhetorical one at that; is there any existing or planned software for the Atari itself that would allow you to create floppy disk image *.ATR's on the FAT32 partition natively? I know this is a very complicated, multilayered topic with questions of sector-size incompatibility and filename length problems for the A8-side with FAT32, while FAT16 could potentially be managed via an RW version of FATFS.SYS but then you lose user-friendly filenames on the PC-side and so on and on. To my mind that is the only thing 'missing' from the SIDELoader - and obviously not 'missing' at all as the SIDELoader is primarily that, a loader. Even it were physically possible to enhance the BIOS code so *.ATR images could be created on a FAT32 CF partition on the A8, mounted in the SIDELoader and then formatted/written to as if one were using an SIO2SD/PC-USB I very much doubt it could be done inside 500bytes!!!

[morelenmir]

Another question has just sprung to mind. I was reading issue 32 of Page 6 which has a very interesting section of DIY expansions to the XL's and XE's. It talks about 'using the PBI as a device' and mentions for this you must have a 2k 'device handler' programme that somehow occupies the same space as the floating-point ROM. Is this the same thing as the PBI BIOS for the U1MB?