New (alt) BIOS for Ultimate 1MB/Incognito

[piomet]

Hi!

 

I have mounted Lotharek's Covox on the board.It's a great piece of hardware, but I'm switching covox to disabled in ultimate setup and covox still works. Any ideas?

[flashjazzcat]

No idea. I don't have a Lotharek Covox to test. But the Covox is not detectable in software, so I have to assume the hardware is not compatible with the switching method used by the plugin. I believe it works with Candle's Covox.

 

But as I say: without hardware, can't test.

[_The Doctor__]

isn't the range on some selected but jumper, or perhaps use the control line for a switcher... they made some ready to go socket pcb using control line from u1m yes?

[flashjazzcat]

Yes: it's possible the device isn't installed correctly. I can't remember the Covox signal pin off-hand but I'm sure it's in the firmware manual.

[piomet]

https://lotharek.pl/productdetail.php?id=192

Instalation of this covox is very simple. in my opinion. It's socketed under PIA. I've no idea what goes wrong.

I've another one problem. Maybe somebody could help me. I connected covox and pokey to one output and sound on amp is very distorted. Separately it's all ok.

Now to play covox/pokey I must switch cable to two joints.

Edited November 9, 2018 by piomet

[_The Doctor__]

Connections to be made with small wires:

• CTRL - pin 9 LS138 on Atari board

O2 signal problems:

• on majority of ATARIs middle and RIGHT pins of JP1 connector shall be jumpered / connected. No further actions required
• or
• if your sound is distorted, remove the jumper, then connect RIGHT pin of JP1 to CPU pin 39

If still a problem post pictures

Edited November 9, 2018 by _The Doctor__

[flashjazzcat]

Just looked at Lotharek's product page, and interestingly enough it makes no mention of Ultimate 1MB at all, let alone whether or how the Covox can be toggled under software control. In any case: the default BIOS plugin's Covox toggle is on pin M1 (Stereo being on M0). This is a logic high/low signal and the firmware does not perform any 'are you there' tests on the device at the other end of the wire, since Covox has no signature bytes and cannot be detected in software. I don't even know if this board decodes at the same address as Candle's board (there are several possible address ranges). If it's possible to support this board, I'll be more than happy to create a plugin for it.

 

EDIT: LS138 pin 9 = 0xD6xx, so that gives us a clue about the decoding address.

Edited November 9, 2018 by flashjazzcat

[_The Doctor__]

I couldn't see the traces in the picture to see what jumper pin would be used to toggle it. I wish he'd post more info on what he's selling. but at least you can get a distortion fix from my post.

[flashjazzcat]

I have emailed Lotharek with a list of questions. It may be that the device is completely missing an on/off pin.

Edited November 9, 2018 by flashjazzcat

[piomet]

I couldn't see the traces in the picture to see what jumper pin would be used to toggle it. I wish he'd post more info on what he's selling. but at least you can get a distortion fix from my post.

 

Connections I've made are correct for sure. I've connected covox to cpu pin39, too for check the difference. But distorted sound is only when pokey and covox outs are connected together to common amp input. It looks like covox signal is stronger than pokey. I've tried to put resistors on covox out but it doesn't helps.I'm not enough strong in electronic to know how to fix that.

Edited November 9, 2018 by piomet

[flashjazzcat]

Yep: no facility to disable Covox in software with this board, confirmed. Apparently no reason could be conceived why one would want to turn it off, although Candle seems to have thought it worth including.

 

So: please don't expect that U1MB's Covox menu option (either original or new firmware) is going to do anything with this board: it won't.

[_The Doctor__]

sad very sad. Oh well, scratching that one off the list. post picture of install, add a resistor or diode on wire to amp. It may lower threshold or provide some isolation. very odd.

 

other choice fix Phi 2 with faster buffer chip like is done to almost all other pbi/noise/cart/bus issues

[piomet]

sad very sad. Oh well, scratching that one off the list. post picture of install, add a resistor or diode on wire to amp. It may lower threshold or provide some isolation. very odd.

 

other choice fix Phi 2 with faster buffer chip like is done to almost all other pbi/noise/cart/bus issues

 

What kind of diode should I wire?

Edited November 9, 2018 by piomet

[_The Doctor__]

my order of attack is always

 

1. phi fix (works great, if not then 2) but leave this installed

2. resistor ( i don't bother calculation any more, I just hook up a pot and turn till the issue goes away, then I read the value and run with it. If it fails to help I move on to #3

3. if all else fails diode. fastest kind I find in the drawer with the lowest voltage drop... I start with bat 1n5 1n8 and work towards 1n4... i pick the one with just enough drop to make things happy but is still fast enough not to kill things.

 

Phi fix is almost always cure what ails the machine, resistors adjust levels, diodes protect or isolate. Since I do not have your machine or boards we can only provide whats worked for related issues and ask you try these it only helps but what is correct sometimes involves a small experiment. like use a pot instead of a calculator to fine what resistor to use..

Since we all love tech talk, usually picking darlington transistors are the way to go for video or noise issues in video and some circuits.

Edited November 9, 2018 by _The Doctor__

[piomet]

I added resistors 30k on covox l/r out, and sound is quite ok by covox and pokeys There's a little hum noise from genuine atari audio circuit. But it's evident I think on majority stock Atari.

[_The Doctor__]

glad it helped!

with this combination, could be isolation issue. ground loop or noisy power supply...

Edited November 10, 2018 by _The Doctor__

[piomet]

Yeah, My Atari has really spaghetti wiring inside. Ultimate, Sio2SD, TKII stereo, Sophia and Covox. All packed in ITXcase. Thanks a lot for yours help!!!

[+tf_hh]

I have mounted Lotharek's Covox on the board.It's a great piece of hardware, but I'm switching covox to disabled in ultimate setup and covox still works. Any ideas?

 

As already mentioned, Covox can´t be detected by software. It uses 4 bytes of address space and uses typically the addresses $0280 or $D600. Covox switching on/off is only possible with the Stereoboard made by Candle.

[flashjazzcat]

As already mentioned, Covox can´t be detected by software. It uses 4 bytes of address space and uses typically the addresses $0280 or $D600. Covox switching on/off is only possible with the Stereoboard made by Candle.

Covox can't be detected in software, so its presence has to be assumed, which is the exact reason I implemented a system of plug-ins for the U1MB BIOS (if there's no Covox on the machine, omit Covox switching entirely). But not being detectable in software does not preclude switching. The device simply needs a logic switch which can be connected to U1MB's M1 pin. Alternatively, some hidden register accessible via an unlock sequence could be supported by a plug-in. But I really don't know how important or otherwise it is to be able to turn Covox on and off anyway.

[Faicuai]

Now that we have a much better time / place to review where things were last left:

 

http://atariage.com/forums/topic/285987-how-to-xfer-software-from-pc-to-an-8-bit-platform/?p=4179063

 

Since I am a pretty poor short-stories writer (they always come out eternally long), here it goes:

1. If a sign of PBI polling is taking place while we can hear the classical SIO "farting" at the very first Gr.0 session during boot, that means we are already WAY, WAY beyond the OS query-and-control of Basic. Accomplishing such task at such height of the game is nothing sort of gymnastically miraculous, because by this time, Left-cart executive privilege has been checked (Diagnostics), HW is already initialized, Memory has bee already sized and stage-2 tested, LEFT-cart initialized (in my case, LEFT and RIGHT carts are now correctly detected and processed during power-up), and system is ready for OS "DBA" (disk-boot-attempt), if called for.
2. The correct / right point and moment to address (and HOLD firmly) BASIC on its tracks, is during OS stage called "PMI" (Perform Miscellaneous Initialization). The OS ALREADY has the necessary code to make this happen. At this stage, NO RAM has been sized & tested, carts HAVE NOT yet been booted (except diagnostics), etc. In fact, the first step at this point is PMI's "IHW" (Initialize HW), which will take care of custom-chips registers initialization and right-after Basic gets DISABLED by default, exactly at locations $C487 to $C48C. The very next step is to test for OPTION console-key (on XL) or OPTION & SELECT keys (on XEGS, which works for XLs too). The latter is present on XEGSr04 OS load exactly at location $C49A, from which CPU jumps unconditionally to a functional-enhancement segment of code ADDED by Atari in location $CB65 (for XEGS) (also in my opinion, the overall best XL/XE-type OS load in existence).
3. Upon final testing of OPTION&SELECT keys, it returns with conditional .JMPs BACK to $C4A1 (to ENABLE Basic if OPTION key was NOT held) or $C4A9 if OPTION key was actually held. It is there were the OS naturally firmly grabs Basic with its claws (instead of later stages, and much less during PBI polling, SIO booting, etc.) Obviously, working with the natural (and unmodified) behavior of the OS requires us to follow it until the first viable place where we can fool it, which is logically what PBI Bios does for handling Basic (zero complains, there).
4. In any case, and now that LEFT and RIGHT cart are fully and properly bootable on 800-i under XL/XE, it turns out that inserting a RIGHT-cart (after having BASIC disabled in BIOS, and of course PBI extension=ON) will, in fact, perfectly boot the RIGHT cart (e.g. Monkey Wrench II) but in the process, it will ALSO boot Basic, who joins the party without an invitation (!) And this is happening because it seems we are catching PBI-bios management of Basic with its pants-down, still... :-) Proof of this is that, if I keep OPTION key pressed right before blue-screen appears, the RIGHT-cart is the ONLY one that gets fully booted, and Basic is kept out of the party (which is correct, and how it automatically happens on OS-b if Basic is not present).
5. The above ordeal of a summary, is nothing else but the rational for trying to read BIOS' Basic-option (enabled / disabled) DIRECTLY from OS, thus making the OS ALSO aware of it (BUT still preserving its current logic flow and key scans, so it runs exactly as originally designed, if such BIOS inputs are NOT found). This would also mean that a SYSTEM RESET (warm start) or another forced COLD-START would NOT bring Basic back as long as it remains disabled in BIOS (which is a consistent and preferable behavior, in my opinion).

Reading stuff from $DXXX will most likely involve introducing an additional branch of code (accessed also via JMP or JSR) somewhere on the OS, where there is basically NO more significant space left (this is what I need to study). Reading a preset pair-values from Page0, instead, allows to use exactly the same code and space already in OS, and most likely only ONE byte is all that would be needed to change. The problem, of course, is that at this stage (PMI / IHW) the memory still shows "power-up" content, which is mostly garbage, has not yet been cleared, and cannot be unconditionally read or used, unless it is ALWAYS pre-set with some usable value.

 

Well, some food for thought...

Edited December 19, 2018 by Faicuai

[flashjazzcat]

Well, conciseness would definitely be appreciated.

 

The reason BASIC disabling fails when the right cart is present is that the PBI BIOS checks for RAM at $8000 before patching the E: handler, since the E: handler patch needs this area to be RAM. This avoids the feature causing a crash with a 16K cart (and with a right cart, it appears).

 

If I move the patch so that it completely avoids the left and right cart regions (which seemed a complete waste of time for the sake of a handful of 16K left carts, I have to say), it will work correctly with right carts too. But the most important reason for disabling BASIC is to allow ATRs and hard disk partitions which require internal BASIC to be suppressed to boot without the Option key being held down. There's a separate mechanism for disabling BASIC in this scenario, and that works regardless of whether the 'BASIC disable' feature is activated or not, and regardless of whether it is successful in the face of cartridge ROM blockage.

 

So - bearing in mind the fix for right/16K carts is easy enough and I feel sufficiently worn down now to implement it, I'm going to decline on feeding information to the underlying OS via base RAM. If the OS still wishes to control the state of internal BASIC even after BIOS management is working with 16K and right carts, it's free to do so. The OS already polls every PBI device on the system, and all you have to do in addition to that is look for the Incognito PBI BIOS signature, check the config record, and if BASIC is disabled via either method (i.e. persistently or pending an ATR or HDD boot), disable BASIC yourself and (preferably) clear the internal BIOS flags before calling the PBI INIT routine so that the firmware doesn't waste time attempting to disable BASIC itself. If you choose to do this and want to know what to turn off, send me a PM about it, since I don't want this thread swamped with a series of bullet-point posts about this one specific feature.

Edited December 19, 2018 by flashjazzcat

[Faicuai]

Well, conciseness would definitely be appreciated.

 

(...)

 

So - bearing in mind the fix for right/16K carts is easy enough and I feel sufficiently worn down now to implement it, (...)

 

Conciseness... that's way harder than 6502 machine language...

 

I believe it would be wonderful to keep anything out the way of $8000 to $BFFF, since such space was designated as Cart-area (either A or B) since the original design of the machines, anyway.

 

If you believe it is doable without that much effort, then I would NOT implement [OS<=>Incognito] signaling, and devote the last 9-10 free bytes I have left on OS rom space to normalize CartA (Left) code posted on TRAMSZ ($06), to strictly adhere to OSb and OS-XL/XE official cart flags (0=absent, 1=present). That would literally make both sides of the equation (BIOS and OS) bullet-proof !

 

Cheers!

Edited December 19, 2018 by Faicuai

[flashjazzcat]

Sure: ideally it would be nice to stay out of the $8000-$9FFF area, even just for the sake of 16K carts. Not that there are all that many of them, and since external cartridges override internal BASIC anyway, and since the BASIC patch is only called when there's RAM at the requisite address, I don't think it's that big of a deal, frankly.

 

I'm not particularly against the idea a custom OS deriving configuration data from the BIOS, either, but if such a protocol were implemented, it would need to be done in a generic fashion and not by just dumping one value required by a particular OS at a particular address. Ultimate 1MB would probably better platform for such things, anyway, since you could easily write a BIOS plugin which set the OS screen colour, etc, and then have a custom OS which defaults to the colour specified in the BIOS configuration. Incognito's firmware has no room for plugins (since the ROM which maps to $5000-$5800 is inaccessible when the config is unlocked; the same ROM works just fine on the U1MB), and since Incognito doesn't have a general purpose logic header, there's no means of controlling Stereo POKEYs and other devices even if plugins could be implemented.

 

In any case: I've had the latest update sitting on ice for about two months now, and once I get that out the door, I'm pretty much done. I'll see what can be done to perfect BASIC control with 16K and right carts, and then give you the opportunity to test it. I had various ideas for further improvements to the loader's FAT FMS, but for the enormous amount of work involved, I guess the functionality would be of niche interest, so I'll just aim to release what's done by the New Year. The fact I'm having to dream up new ideas on how to improve things and the only issue reported since I was told PANG.XEX wouldn't load concerns persistent BASIC suppression not working with right cartridges suggests that I've basically accomplished what I set out to achieve.

Edited December 19, 2018 by flashjazzcat

[Faicuai]

(...)

 

In any case: I've had the latest update sitting on ice for about two months now, and once I get that out the door, I'm pretty much done. I'll see what can be done to perfect BASIC control with 16K and right carts, and then give you the opportunity to test it.

 

(...) The fact I'm having to dream up new ideas on how to improve things and the only issue reported since I was told PANG.XEX wouldn't load concerns persistent BASIC suppression not working with right cartridges suggests that I've basically accomplished what I set out to achieve.

 

THANKS, looking forward to that last test!!!

 

On another note, and not sure how the BIOS is really involved here, I did notice that on Incognito, my 8Mbit AtariMax cart boots nicely with pretty much ANY setting of SDX and PBI Bios I chose, but on my Ultimate1B 800XL, only wat to boot is to have SDX disabled, and PBI enabled, with "HD" drive disabled... a bit bizarre. In other words, NOT the same as Incognito, for sure....

 

Is this normal condition? And if not, what would be considered normal behavior with Ultimate + AtariMax cart?

Edited December 20, 2018 by Faicuai

[flashjazzcat]

The 8Mb AtariMax cart is disabled by writes to the upper half of $D5xx, IIRC, and since both SDX and the hard disk driver address that same area on U1MB machines, disabling them is a must. Indeed, the PBI HDD - when enabled - completely disables external carts on the U1MB anyway if you have the ATR swap button turned on.

 

I would have expected the SDX banking register on the Incognito to wipe out an 8Mb cart in much the same way since it's at the exact same address as the U1MB banking register, but maybe the SDX register isn't write-thru as it is on the U1MB. Technical info is pretty sketchy which is why - I guess - Incognito isn't emulated yet. I have all the info I need to develop firmware, but modelling the hardware is quite a different matter. It keeps development fun having to do everything by trial and error on a real 800.

 

The BIOS update won't be subject to any more changes prior to release if I feel there's a strong chance of breakage elsewhere, since I simply lack the energy to deal with new bugs for the sake of corner case changes. If I could understand the real-world impact of BASIC remaining present behind a right cart or 16K cart, I may feel differently about it, especially since the method of disabling BASIC on the next boot employed by the loader when booting ATRs works regardless of any external cart being present.