Wacky idea - feasible ?

[+Spaced Cowboy]

So I'm playing around designing a PBI interface card right now, it's going to have some RAM on it, and of course I'm thinking of ways in which I could use the resources.

 

One thing I've been thinking of is just how flexible the memory-mapping is. Basically, pull EXTSEL low and you can override the internal RAM on any given bus address, as far as I can tell. Given the size of RAM chips these days, and the ability to remap memory at will, this seems like it might be pretty powerful.

 

Couple that with the fact that the memory-bandwidth within the PBI card is orders of magnitude faster than when transmitting over the PBI, and you have something that could be used as a blitter, software sprites etc with minimal 6502 overhead.

 

One other thing (and the wacky idea of the title) I thought of is that it might be possible to have an APAC screen in that PBI-interfaced RAM, and get the GPRIO changes signaled by IRQs from off-chip. There is an interrupt line available to a PBI device, but from reading, it sounds like this might take a while to get serviced, since the OS goes through a whole "is this your interrupt" thing for each of the 8 possible sources. So how about this:

 

Every data access (including Antic DMA and refresh, indicated by their own signals) will be obvious to a bus observer. Given that the bus can be modeled (ie: determine the difference between an instruction fetch and a data-fetch, and handle refresh cycles, and understand Antic's DMA fetches), it would be possible to, at *any* instruction fetch, inject a BRK instead.

 

Once that happens, the CPU does an NMI with B set in the processor status, and your vector points to a PBI-supplied chunk of RAM which contains the following (or something like it - this is off the top of my head)

What                    Cycles

Inject BRK		7
STA $80			2
LDA #$20/#$C0	        2
STA	GPRIOR		4
PLA			4
PLA			4
LDA #PCL		2
PHA			3
LDA	#PCH		2
PHA			3
LDA	$80		3
RTI			6

Total			42

Do that at the end of every line, alternating what gets stuffed into GPRIOR and you have a low-delay (no STA WSYNC), low-overhead (42 clocks per DLI, 60 frames per second, 200 lines per frame = half a million or so clocks per second, or between 50 and 70% of the CPU left over after Antic steals its cycles). That's feasible for a low-cpu game...

 

Obviously PCH/PCL have to point to the PC-1 of the instruction that was intercepted with BRK, and you also don't burn a POKEY timer

 

So, weird and wacky ? Plausible ? Or just plain nuts ?

 

 

[Rybags]

The annoying thing in the PBI design is there's no way to do proper DMA, ie know in advance that Antic won't have the bus and just take it over yourself.

Though in theory you could do partial emulation and preempt what it is going to do though it would be hard.

 

For graphics stuff, yep like VBXE, the Veronika cart and most accelerators with dedicated Ram that can be shared with Antic, you can rapidly do graphics processing in the background and have Antic display it, exponentially faster than the stock machine could do so.

 

Injecting stuff onto the bus to override the 6502 - not sure there. I think they do that on the 2600 in some cases but for interrupts it's not really necessary.

In any case BRK is about the lowest priority according to the OS routine.

 

The trick you'd want to use is like we use when doing Pokey Timers. Make your PBI IRQ the only possible IRQ source which means you can just assume it's yours, use VIMIRQ and directly do your stuff.

 

Or leave the other stuff alone and just do your own VIMIRQ servicing and give your PBI IRQ better service.

[_The Doctor__]

His experiments may have some merit.

Added ideas on synchronization should allow some stuffing or even direct feeding in some fashion.

Also, what happens when you use all the tricks including shutting Antic Down?

A number of modes and uses might be developed.

[+Spaced Cowboy]

 

Or leave the other stuff alone and just do your own VIMIRQ servicing and give your PBI IRQ better service.

 

 

Yes - I hadn't realized the BRK was so low on the scale...

 

It does seem that intercepting VIMIRQ (and chaining to the existing VIMIRQ pointer as a fallback if it's not PBI-related) might be the easiest way to go. That wouldn't be a *huge* difference in the performance calculation.

 

The PBI interface will still be observing the bus (although maybe not to such an extent) because I do want to provide a very flexible memory-mapping interface - far more flexible than what we have using PORTB.