F18A PEB card?

[+retroclouds]

Here’s something that crossed my mind this weekend. 

What if there would be a custom PEB card with a socket to install an F18a on.

Thay way you could have a second screen, if one manages to tie up the VDP ports to other addresses.

 

Obviously you’d need the software that goes with it and makes use of that second screen.

(ok, got carried away with having a multi-monitor setup for my programming editor).

[+dhe]

The DIGIT AVPC went in the PBOX, so It might be possible.

 

With the new processor for F18A MKII - it might be possible that it has enough cycles and memory to display two screens.

 

 

[Tursi]

Using different access ports, I can't think of any reason it wouldn't work for a second display. Custom software mandatory, as you note. 

 

[matthew180]

I have been thinking about something like this since before the F18A.  I always wanted a dual-screen system for multiplayer games (co-op and head-to-head).  Networked computers solve some of this kind of problem, and push the use for two screens more into the realm of single-person productivity.  The main problem is, as pointed out already, you need new software to take advantage of the 2nd screen.  And these days there are probably fewer people with a PEB vs an alternate solution like a TIPI, NanoPEB, etc..

 

A dedicated F18A PEB card would make this a lot easier (rather than a custom PEB card with a socket).  Having a PEB-size card (or even a quarter of a PEB card) would certainly make the F18A board design much simpler, no PCB-pins to deal with, and the video header could be mounted directly on the board.

 

Anyway, lots of possibilities for something like this, the hardest part is usually narrowing down the options to something that is actionable.  Of course there are also the philosophical arguments of what can be done vs what should be done, etc..  It is always fun to think about though, without worrying about all the details.

[+OLD CS1]

12 hours ago, retroclouds said:

What if there would be a custom PEB card with a socket to install an F18a on.

My original run F18A would suddenly be worth its weight in gold.  On a serious note, it is cool to consider a dual-screen 4A.  The Indivision ECS FF/SD for the Amiga can be stacked to give non-AGA Amigas functioning dual screens.  I really love the idea of a "retro" computer in such a configuration.

[matthew180]

A PEB board with a socket for an F18A would not be that much work.  Without software though, it would be useless.

[+retroclouds]

10 minutes ago, matthew180 said:

A PEB board with a socket for an F18A would not be that much work.  Without software though, it would be useless.

 

True, well should the PEB card become a reality I'll write some software for it.

[+FarmerPotato]

How would the console VDP RAM work? I guess the console VDP would need additional address decoding. 
 

Maybe a primary F18A in the console, with address restricted to 8x0x  addressing, generating interrupts. Then a second VDP in P-Box at a different port?

 

[Tursi]

Yeah, exactly. You'd put it at a different address. Best plan would be to map it to the DSR space like the pCode card, then you can use the >4000 address space for the VDP ports when it was mapped in and guarantee no conflicts.

 

Dealing with the interrupt would be interesting... technically possible since the console can route external interrupts - you could have a different interrupt routine for it. But it's probably easier and just as sane to ignore the external interrupt and not worry about it.

 

 

[+9640News]

1 hour ago, FarmerPotato said:

How would the console VDP RAM work? I guess the console VDP would need additional address decoding. 
 

Maybe a primary F18A in the console, with address restricted to 8x0x  addressing, generating interrupts. Then a second VDP in P-Box at a different port?

 

Yeah, I am sorta thinking something very similar.

 

As there are very limited ports, sector editing assembled code to the new redefined ports may be a rather "simple" task, especially if the code used common VSBR, VMBW, etc. routines.  

 

Beery

[+retroclouds]

5 hours ago, Tursi said:

Yeah, exactly. You'd put it at a different address. Best plan would be to map it to the DSR space like the pCode card, then you can use the >4000 address space for the VDP ports when it was mapped in and guarantee no conflicts.

 

Dealing with the interrupt would be interesting... technically possible since the console can route external interrupts - you could have a different interrupt routine for it. But it's probably easier and just as sane to ignore the external interrupt and not worry about it.

 

 

Yes, with the interrupt handling I see it the same. Would probably just ignore it. 

I do like the idea of having it in the DSR space, but wouldn’t that mean there are issues when trying to acccess storage devices like HDR, IDE, TIPI 

and doing screen updates on the 2nd screen? Would it imply you always have to think about turning the “F18a card” on/off when needed?

 

 

 

 

 

[matthew180]

I don't know all the rules for PEB cards, but if the system address bus is available to every PEB card all the time, then the new VDP could just be mapped into an unused range (of which there are many on the 99/4A), somewhere near the original VDP maybe.  Yes, this means some poorly written legacy software might conflict or cause problems, but the new VDP could also have a lock so only new software could enable it (like the enhanced F18A features).  I suspect there are many ways to solve any problems.

[Tursi]

16 hours ago, retroclouds said:

Yes, with the interrupt handling I see it the same. Would probably just ignore it. 

I do like the idea of having it in the DSR space, but wouldn’t that mean there are issues when trying to acccess storage devices like HDR, IDE, TIPI 

and doing screen updates on the 2nd screen? Would it imply you always have to think about turning the “F18a card” on/off when needed?

You shouldn't leave DSRs enabled when accessing other devices anyway.. turn it on, do your business, then turn it off. It's just one instruction and won't slow you down noticeably. So in short - yes.

16 hours ago, matthew180 said:

I don't know all the rules for PEB cards, but if the system address bus is available to every PEB card all the time, then the new VDP could just be mapped into an unused range (of which there are many on the 99/4A), somewhere near the original VDP maybe.  Yes, this means some poorly written legacy software might conflict or cause problems, but the new VDP could also have a lock so only new software could enable it (like the enhanced F18A features).  I suspect there are many ways to solve any problems.

If you just pick a address and own it, you are guaranteeing conflicts will happen. With such a simple mechanism to guarantee it won't, why worry about coming up with lock systems that would ultimately be more complex than SBO 0 anyway?

[+FarmerPotato]

The way I've imagined multiple VDPs is further decoding the read/write address space. First hurdle,  8C02 and 8C12 are distinct VDPWA and writing to one does not clobber the other. 

Then, a cool feat would be to have GPLWS R15 point to one or the other. If the console software is consistent, then any VDP access is relative to this.
 

You'd have to copy the original 16K to the other to keep GPL functioning. 
 

TI set guidelines for DSR authors to use the base addresses in GPLWS, not hard coded ones. That was to allow future consoles to have different memory mapped addresses. I wonder how consistently this was done?
 

One might imagine moving the GPL environment to VDP2.. then running another program  using VDP1, esp one that assumed 8c02.) Meanwhile VDP1 would just sit there statically, until you jumped back into it.

 

You'd have to preserve PAD as well,  so it would take a bit more Magic. 
 

 

 

 

[matthew180]

53 minutes ago, Tursi said:

If you just pick a address and own it, you are guaranteeing conflicts will happen. With such a simple mechanism to guarantee it won't, why worry about coming up with lock systems that would ultimately be more complex than SBO 0 anyway?

 

I don't think I have ever written any assembly that deals with an expansion card that needs to be enabled via a CRU bit, so I'm not sure of the overhead.  Maybe it is just simple, as you mentioned?  But how are CRU bits assigned?  If they are per PEB slot, then do you have to enable each and poll the device to know what cards are on which CRU bits?

 

Eh, no need to explain it to me, I can look it up.  I'm just musing anyway.

[Tursi]

7 hours ago, FarmerPotato said:

TI set guidelines for DSR authors to use the base addresses in GPLWS, not hard coded ones. That was to allow future consoles to have different memory mapped addresses. I wonder how consistently this was done?

Nothing on the TI was done consistently.  But, yeah, it'd probably work for most GPL software.

 

Technically nothing prevents it from working. I just wouldn't want to have to deal with the software that wasn't well written. I got enough of that with Classic99.

 

7 hours ago, matthew180 said:

 

I don't think I have ever written any assembly that deals with an expansion card that needs to be enabled via a CRU bit, so I'm not sure of the overhead.  Maybe it is just simple, as you mentioned?  But how are CRU bits assigned?  If they are per PEB slot, then do you have to enable each and poll the device to know what cards are on which CRU bits?

 

Eh, no need to explain it to me, I can look it up.  I'm just musing anyway.

You know I like to explain.

 

Turning a card on and off is just done by setting its base CRU bit to 0, so you load R12 with the address, and SBO 0 to turn it on, SBZ 0 to turn it off. Very small overhead, especially if you're doing a bulk transaction (which would make the most sense for a second VDP.)

 

The PEB slots are electrically identical, so the CRU bits are assigned by the cards themselves. User cards usually use a dip switch to allow the owner to set a non-conflicting address.