Jump to content
IGNORED

Introducing: AntiX, the ANTIC Switch !


Level42

Recommended Posts

The issue is that Jon's firmware does advanced tricks to detect f.i. if there is a Stereo POKEY installed. Personally I wouldn't need that detection because I "know" I have one installed. Maybe a special version of the U1MB firmware could be made that refrains from this advanced toggling of the U1MB output ports during boot-up and include AntiX as one of the devices in the menu.

No, that's not the issue. It would be an issue if you connected AntiX to the M0 header pin using the default BIOS plugin (since that pin controls Stereo POKEY), but it would make no sense to hook it up there when it's intended to drive stereo boards. Use either of the unused signals (S0 or S1) instead, and hardware detection becomes a non-issue, since both the spare signals can be toggled without restriction.

 

I think you're actually referring to the fact the Aux register bits of S0 and S1 ended up being set or cleared as part of the boot process (but not for the purpose of hardware detection). I recall masking out these bits, but since a bit ultimately needs to be set anyway in order to select one ANTIC or the other, it didn't make much difference.

 

The original BIOS succeeds entirely accidentally in accomplishing a software switch, and of course it's actually necessary to use one of the already assigned Aux signals (e.g. M0) there since the others are entirely unusable with the original firmware. The only way I can simulate the exact same circumstances of operation would be to code the new BIOS in exactly the same way as Candle's, which would result in Candle's BIOS. Mine is a ground up re-write, so the same happy accidents will never occur. :)

 

I don't know, Jon definitely put a number of hours of trying to get it to work but I think he lost interest because AntiX is a pretty dumb and "rough" device in that it is not a software controlled thing. This normally requires that AntiX is switched BEFORE powering up and left alone until switched off. I'm not saying it damages anything when you try to switch on the fly, but it sure crashes anything that is running when you try.

Yes: the issue I met (as I recall) was that switching ANTICs would heavily destabilise the system regardless of the state of NMIs, DMA, etc, and I could find no way to accomplish clean switching... at least nothing I'd be happy to publish. Developers are free to attempt a plugin implementation, but I doubt the task could be accomplished entirely in the plugin context anyway.

 

Some kind of latch connected to the system reset line would have fixed the issue (so that the pending ANTIC didn't appear on the bus until the system was held in a reset state), but in the absence of that: yes, I gave up, and consider a hard switch to be the sanest solution in the circumstances.

Edited by flashjazzcat
  • Like 1
Link to comment
Share on other sites

Some kind of latch connected to the system reset line would have fixed the issue (so that the pending ANTIC didn't appear on the bus until the system was held in a reset state), but in the absence of that: yes, I gave up, and consider a hard switch to be the sanest solution in the circumstances.

 

Just a wild idea, could you use S0 to select which Antic and connect S1 through a resistor to the reset line?

 

Hmm, I guess once you pull S1 to low, the code will stop running and it will never get out of the reset state :)

 

I think this could be fixed with a small PIC or TinyAVR in between. It "listens" for the reset pulse on S1, going low, going high, and then issue a reset pulse to the true Atari reset line. Needs more hardware though.

  • Like 1
Link to comment
Share on other sites

Interesting idea. :) I guess more hardware is definitely needed, which is what I suggested at the outset. I appreciated the desire to try and keep things simple, though.

 

The problem is simply that one or the other ANTIC jumps on or off the bus the instant - say - S0 is written to, and even if S0 powers on in a defined state (say, logic 0), when the system is configured to use the ANTIC selected by logic 1, a nasty screen glitch at the very least is par for the course as the correct chip is selected and appears on the bus with DMA, NMI, etc, in an uninitialised state.

 

So yeah: doing the switch while reset is asserted would be highly desirable.

Link to comment
Share on other sites

As ivop suggested, a PIC MCU could be programmed to do this. Although it almost seems a waste of the resources on an 8-pin PIC MCU. However it would offer a simple, small , and cheap solution for implementing any kind of automatic switching scheme that was desired, while taking up very little space. Just as an example, something like the PIC12F1572 goes for about 71 cents from Digi-Key.

Link to comment
Share on other sites

Hello guys

 

Since you're gonna need the extra electronics (a PIC in this case) anyway, wouldn't it be possible to have it detect a switch (from 0 to 1 or vice versa) and have it trigger the reset? That way, you only need one output on the U1MB.

 

Sincerely

 

Mathy

Link to comment
Share on other sites

Since you're gonna need the extra electronics (a PIC in this case) anyway, wouldn't it be possible to have it detect a switch (from 0 to 1 or vice versa) and have it trigger the reset? That way, you only need one output on the U1MB.

Great minds think a like... that's exactly what I was thinking :) .

 

There will also be several left over PIC I/O lines. What should those be used for? Be nice to get something extra at the same time.

  • Like 1
Link to comment
Share on other sites

I wish I would understand more about hardware and software....I'm really not that great at electronics. I learned enough to service it, not design complex things.

 

This is why AntiX is a very simple device.

 

I stand corrected on the M ports /stereo pokey detection at boot up by U1MB.

 

What I still don't understand it why the S ports need to toggle during boot up. This would affect _any_ device connected to it....and is surely not desirable for any other device as well...

 

The _only_ requirement AntiX has is one of the S ports to be either high or low _and remain_ in that state for the rest of the time the machine is running....

 

My brain is probably to simple to not understand why U1MB cannot behave that way with your firmware Jon.

Candle's firmware does NOT toggle the S outputs during boot. They are either high of low depending on what you choose in the menu the next time you do a cold-boot. This is what we need...and I just don't understand why it is not possible to have your firmware act the same way.

 

Look, there is zero obligation for you to even try to get this working...but it feels like something _so_ simple for me.

 

Please explain me....WHY do the S ports toggle during boot with your firmware, but not with Candle's ?

 

[EDIT] Mmmm, I might have had AntiX connected to one of the M ports and use the Stereo toggling in the menu with the original U1MB firmware. Are the M and S ports so much different then ?

 

Wouldn't adding anything in hardware cause the selection between ANTICs be "too late" ? In theory, the selection probably has to be done before the very first clock-cycle because a regular machine has ANTIC "ready" from the very first instance ?

Edited by Level42
Link to comment
Share on other sites

The unused signals aren't 'toggled' at all. Let's look at bit usage in the auxiliary ('Aux') configuration register at $D381:

 

;	$D381 (Aux):
;	bit 0: stereo (pin M0, P4)  (0 = off, 1 = on)
;	bit 1: covox (pin M1, P4) (0 = off, 1 = on)
;	bit 2: pin S0, P4 (0 = off, 1 = on)
;	bit 3: pin S1, P4 (0 = off, 1 = on)
;	bit 4-5: VBXE (00 = 0xD640, 01 = 0xD740, 10 = off, 11 = off)
;	bit 6: Soundboard enable/disable (0 = off, 1 = on)
;	bit 7: Flash write disable (0 = flashable, 1 = disabled)

During BIOS initialisation, bits 4-5 are written in order to establish whether VBXE is present (it's first disabled entirely, then enabled at either address and an attempt made to communicate with the AVR chip). At that time, all other bits of the aux register are zeroed out. If we assume that the Aux register powers on or comes out of reset with a value of zero, the bit 2 and 3 (S0 and S1) haven't been 'toggled' at all. Likewise with the default plugin, which (as you have observed) manipulates bit 0 of the configuration register in order to establish the presence of a stereo POKEY board. S0 and S1 just end up having zero written to them a couple of times until finally - when we leave the BIOS setup menu - whatever settings the user chose for S0 and S1 (Devices 3 and 4 in the 'Device Control' menu when the default plugin is used) are written to bits 2 and 3.

 

It's easy to see that the only time bits 2 and 3 will appear to deviate from the desired value is if the desired value is 1, not 0. If that's the case, those bits will remain at '1' until the user's settings are finally written to $D381 just before the configuration is locked.

 

Candle's BIOS made no attempt to verify the existence of hardware controlled by the M0 (Stereo POKEY) and VB (VBXE) signals, and probably didn't write to the Aux register at all until the user settings were written to $D381 immediately prior to the config lock. One unfortunate result of this was that several users has wired up their U-Switch controlled Stereo POKEY boards and happily assumed all was working until they upgraded to my firmware, at which point they believed they'd found a bug since their Stereo boards were either not detected or could not be switched on or off. What this actually revealed, in 100 per cent of cases, was not a bug in the firmware but a wiring error or faulty U-Switch, which in turn meant that Stereo switching functionality had never worked on their machines in the first place, even when running the original BIOS. :)

 

The difference between the Mx ports and the Sx ports when the default plugin is used is simple: no functionality is prescribed to the Sx ports, and no toggling is performed. Sx remain at '0' until the configuration is saved upon leaving the BIOS setup menu (where they'll still remain at '0' unless you Enabled Device 3 or 4 in the Device Control menu).

 

Now, the problem I can see with allowing a PIC to trigger a system reset as soon as the state of D2 at $D381 changes is that $D381 must be written to prior to the configuration being locked (via a write to the main configuration register at $D380 with D7 = 1). So if system reset was triggered by a change to $D381 D2, the configuration would not be locked and the CPU would immediately jump back to the start address of the BIOS with the configuration unlocked. This time, however, the write to $D381 would not necessarily result in a bit flip (assuming the CPLD does not reset the port bits to 0 on system reset), so the firmware might manage to lock the configuration and proceed to initialise the OS as normal. If the CPLD did set $D381 to $00 and we kept writing '1' to bit 2, however, we would clearly enter and endless loop of system resets.

 

So: we'd have to try that in order to find out if it would work, basically.

 

PS: If the PIC simply maintained a shadow of the current 'state' of the switch and reacted to a change, that would probably have a chance of working.

Edited by flashjazzcat
  • Like 1
Link to comment
Share on other sites

I am positive I measured level changes in the S signals during boot-up. This is what causes the machine to crash, because the result of this toggling between 0 and 1 means AntiX is switching between ANTICs during boot-up....

 

If this is because of VBXE detection: you cannot have a VBXE AND AntiX inside your machine at the same time, so if one chooses for AntiX there is no use in sensing VBXE........would this open up the route to two versions of your firmware ?

Edited by Level42
Link to comment
Share on other sites

I am positive I measured level changes in the S signals during boot-up. This is what causes the machine to crash, because the result of this toggling between 0 and 1 means AntiX is switching between ANTICs during boot-up....

Here's a list of all the writes to $D381 during a firmware boot:

 

post-21964-0-09498000-1549211611.png

 

I don't see any evidence of bits 2 and 3 being toggled.

 

If this is because of VBXE detection: you cannot have a VBXE AND AntiX inside your machine at the same time, so if one chooses for AntiX there is no use in sensing VBXE........would this open up the route to two versions of your firmware ?

As you can see, it's not because of VBXE detection (which is part of the core BIOS code) and not part of Stereo POKEY detection (which is part of the plugin), so not testing for VBXE would accomplish nothing at all.

 

I remember suggesting some kind of latching mechanism to you when you were designing AntiX, but I appreciate that you wanted to keep the device as simple as possible. Unfortunately, if you design a device which switches ANTICs on the fly the moment the switching logic changes, it's a little bit trickier to implement software switching. A simple latching mechanism to defer switching to a more opportune moment (e.g. the next system reset) would completely fix the issue, but you appear to be against that. Having spent a whole Sunday evening trying to work around this a year or so back, there's little more I can do.

 

Link to comment
Share on other sites

Surely we only need one U1MB output anyway? The PIC just needs to select ANTIC based on the state of S0 whenever reset is pressed. That's all. I didn't envisage trying to trigger reset in software. I suppose it could work but there may be unwelcome side-effects.

 

But that is what I was hinting at :)

 

With one Sx line: CPU toggles Sx, PIC/AVR detects toggle, pulls down /reset, switches ANTIC, releases /reset. Instant software toggle, or am I missing something?

Edited by ivop
Link to comment
Share on other sites

But that is what I was hinting at :)

 

With one Sx line: CPU toggles Sx, PIC/AVR detects toggle, pulls down /reset, switches ANTIC, releases /reset. Instant software toggle, or am I missing something?

I know it's what you're hinting at. All I'm saying is that I originally envisaged the user having to press reset in order to enact the swap. I'm also saying that pulling reset low as soon as Sx changes might work or might create problems.

 

Like I say: if it worked as you describe, the first attempt at a configuration lock (shortly after $D381 is written) would fail since the machine would go back into a reset state. Providing the next write to $D381 (as the firmware attempts to lock the configuration a second time) does not trigger reset again (which it wouldn't, since the same value is being written again), I guess it has every chance of working.

  • Like 1
Link to comment
Share on other sites

I know it's what you're hinting at. All I'm saying is that I originally envisaged the user having to press reset in order to enact the swap. I'm also saying that pulling reset low as soon as Sx changes might work or might create problems.

 

Like I say: if it worked as you describe, the first attempt at a configuration lock (shortly after $D381 is written) would fail since the machine would go back into a reset state. Providing the next write to $D381 (as the firmware attempts to lock the configuration a second time) does not trigger reset again (which it wouldn't, since the same value is being written again), I guess it has every chance of working.

 

Would it help if the PIC/AVR delayed its "/reset" a few milliseconds (or whatever time is needed) so your BIOS can leave the U1MB in an appropriate state for either a warmstart or coldstart?

Link to comment
Share on other sites

I'm sort of undecided there. The outcome is going to be the same in either case. Without a delay, locking of the configuration will be interrupted and the firmware will essentially be restarted and exit normally the second time around. With a delay, the configuration would be locked, and OS jumped back into, and then the same sequence of events as previously described would occur. Delay might be safer since some internal firmware flags might get screwed up otherwise, although only about a dozen instructions are executed between $D381 being written to the final time and the configuration being locked.

Link to comment
Share on other sites

I love it when Ican do a cold start reset without power cycling with upgrades and loading devices, but when it comes to switching between Antic chips, whether I use it with an U1MB or not I just have expected to shut down, flip the switch, and power back up if I want to use the other Antic. I think it's been made out to be more important than need be, considering all that would have to be changed for a cold start reset option compatible with other upgrade's cold start reset options.

Edited by Gunstar
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Hey guys,

 

Just to inform you. I am busy with moving my websites (a.o. atarimuseum.nl and rewindgames.com) to a new hosting provider. The old hosting provider has decided to increase their hosting prices with 325%.....

 

The antix website is part of one of my websites. So the antix website will not be available for a few days, but will be back soon!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...