Electron to BBC Conversions
Re: Electron to BBC Conversions
Not sure if this affects your reasoning, but the RAM is arranged such that you can get two consecutive nibbles in two accesses - or at least, two nibbles from the same page. Which is to say, you don't get two arbitrary accesses.
Re: Electron to BBC Conversions
I've finally tracked down an earlier StarDot conversation which is quite illuminating, if only in confirming what I'd managed to deduce somewhat painfully in this thread.
It does appear that the Electron is modelling a 2MHz 8-bit random-access memory subsystem, which is then shared between the CPU and video.
The page-access issue is a good point. According to the circuit diagram, the Electron uses 4164-15 parts, which take 260ns for a random access, 145ns for paged access. Hence, 405ns for random access to a byte consisting of two nibbles. But, alas, 520ns for two random-access nibbles - not quite fast enough. )-8
Conversely, now I see the full horror of how the Electron implemented two entirely different strategies for bus arbitration between CPU and video depending on whether it was in MODE0/1/2/3 or MODE4/5/6, I can't help feeling that a single-byte video FIFO would actually have been simpler, as well as giving better performance in all cases. Have a "FIFO demand" signal which becomes true during each hsync pulse and false once the final byte for the line has been read. Then, every 2MHz cycle: is the FIFO empty and in demand? If so, fetch a byte for video. If not, let the CPU have a cycle. Given one byte is always enough to keep the video subsystem happy for at least 650ns and a CPU memory access takes 500ns, that could never fail.
It does appear that the Electron is modelling a 2MHz 8-bit random-access memory subsystem, which is then shared between the CPU and video.
The page-access issue is a good point. According to the circuit diagram, the Electron uses 4164-15 parts, which take 260ns for a random access, 145ns for paged access. Hence, 405ns for random access to a byte consisting of two nibbles. But, alas, 520ns for two random-access nibbles - not quite fast enough. )-8
Conversely, now I see the full horror of how the Electron implemented two entirely different strategies for bus arbitration between CPU and video depending on whether it was in MODE0/1/2/3 or MODE4/5/6, I can't help feeling that a single-byte video FIFO would actually have been simpler, as well as giving better performance in all cases. Have a "FIFO demand" signal which becomes true during each hsync pulse and false once the final byte for the line has been read. Then, every 2MHz cycle: is the FIFO empty and in demand? If so, fetch a byte for video. If not, let the CPU have a cycle. Given one byte is always enough to keep the video subsystem happy for at least 650ns and a CPU memory access takes 500ns, that could never fail.
Re: Electron to BBC Conversions
Bear in mind the Electron ULA was (is) completely full, to the point of only just being routeable. So it's possible there are better ways of arranging things which there just isn't room for - but also possible that there are better ways which weren't thought of.
Re: Electron to BBC Conversions
Agreed. But giving the memory subsystem to the CPU and video on alternate cycles in some modes, CPU during flyback and video during raster output in other modes, sounds to me a whole bunch more resource-intensive than an 8-bit edge-triggered latch.
(In an ideal world, you'd also arrange that the CPU not crash when you changed from one to the other. (-8 )
(In an ideal world, you'd also arrange that the CPU not crash when you changed from one to the other. (-8 )
Re: Electron to BBC Conversions
I suppose with a replacement ULA project you could experiment with these kinds of tactics - if you had the self-control to use only the original nibble RAM and not implement a simpler but more costly shadowing scheme!
The efforts to reverse engineer the ULA might well give us some interesting information about the implementation and the layout.
The efforts to reverse engineer the ULA might well give us some interesting information about the implementation and the layout.
Re: Electron to BBC Conversions
Indeed. It'll be interesting to see what those projects come up with!
-
- Posts: 563
- Joined: Sat Dec 23, 2000 5:56 pm
- Contact:
Re: Electron to BBC Conversions
Sorry, I was on holiday!
The Electron's 6502:
Clock Signal has no such error and is the only emulator to get the proper numbers for that benchmark.
So, for software that isn't racing the beam you're probably fine just waiting for the display interrupt then burning half the available cycles before proceeding.
Re: palettes and modes, switching palettes on the 100Hz interrupt is the most common way to hide program data within the display, given that there's no CRTC so you can't just redefine the display size to increase your room for program data.
More complicated things, off the top of my head, if memory serves:
Re: Pi options, given that there are almost no examples of a hardware scroll (Firetrack as mentioned for a smooth scroll, also Syncron and probably others I've forgotten just use the 8-pixel vertical scroll), I would dare imagine that differential frame analysis would work pretty well, though the problem would be which graphics mode to use on the BBC. E.g. Sphere of Destiny uses all eight colours and contains a 320px section of display for informational text. So if you don't want to get into supplying the BBC with mode-change locations then you'll probably have to mess up the text.
The Electron's 6502:
- runs at 2Mhz when accessing ROMs in any mode;
- runs at 1Mhz when accessing RAM in modes 4–6, regardless of the current raster position;
- runs at 1Mhz when accessing RAM in modes 0–3 if pixels are not currently being output; if pixels are currently being output then the CPU clock is stopped until they are no longer being output. So 0–2 are slower than 3, because 2/10ths of lines in 3 are blank, and all of them are the same speed as modes 4–6 when drawing the border.
Clock Signal has no such error and is the only emulator to get the proper numbers for that benchmark.
So, for software that isn't racing the beam you're probably fine just waiting for the display interrupt then burning half the available cycles before proceeding.
Re: palettes and modes, switching palettes on the 100Hz interrupt is the most common way to hide program data within the display, given that there's no CRTC so you can't just redefine the display size to increase your room for program data.
More complicated things, off the top of my head, if memory serves:
- Gauntlet (in the game menu), Kane and at least one of the flight simulators that is probably 737 Flight Path change mode mid display. The latter does it several times for a menu screen, switching between the 80-column and 40-column modes;
- Southern Belle and Evening Star also use a palette swap to hide data, but trigger on a tape data-related interrupt;
- Spy vs Spy switches to black at the 100Hz interrupt, then busy loops for a while, then switches back to colours. So it hides data in a thin band in the middle of the display;
- Sphere of Destiny is almost entirely a busy palette-changing loop;
- Firetrack switches between modes 6 and 5 after counting in a busy loop to get a hardware scroll.
Re: Pi options, given that there are almost no examples of a hardware scroll (Firetrack as mentioned for a smooth scroll, also Syncron and probably others I've forgotten just use the 8-pixel vertical scroll), I would dare imagine that differential frame analysis would work pretty well, though the problem would be which graphics mode to use on the BBC. E.g. Sphere of Destiny uses all eight colours and contains a 320px section of display for informational text. So if you don't want to get into supplying the BBC with mode-change locations then you'll probably have to mess up the text.
Re: Electron to BBC Conversions
Really? Not 2MHz?ThomasHarte wrote:
- runs at 1Mhz when accessing RAM in modes 0–3 if pixels are not currently being output; if pixels are currently being output then the CPU clock is stopped until they are no longer being output.
Re: Electron to BBC Conversions
Yep, the Electron never accesses RAM (or &FCxx/FDxx, and maybe &FExx) faster than 1MHz.
SW/EE from New Zealand, now in Mountain View, CA, making Beeb/Elk/Arc hardware projects for fun.
Most interesting: Arcflash, POST Box, Ultimate Electron Upgrade
Most interesting: Arcflash, POST Box, Ultimate Electron Upgrade
Re: Electron to BBC Conversions
The 1MHz access is mentioned in chapter 5 of the Acorn Electron Service Manual.
-
- Posts: 563
- Joined: Sat Dec 23, 2000 5:56 pm
- Contact:
Re: Electron to BBC Conversions
I checked, and it is Flight Path 737 I was thinking of, as attached.
'Flying Experience' and 'Select Level (1 to 6)' are Mode 1; the six numbered options are Mode 4 with busy wait palette changes. So that's all eight colours on a 320px width display. I think possibly a developer found himself with an opportunity for amusement.
The actual game also has a 1/6 mode split as pictured, but just the one.
Also, a quick bit of extra detail on my ElectrEm comments: rather than applying a cost of two or three 2Mhz cycle lengths when a 1Mhz access follows a 2Mhz access depending on phase, it applies a cost of 1 or 2, owing to my misreading of the EAUG. At the time I understood memory to be pumping out as though an 8-bit 2Mhz device, so either you hit the 2Mhz-sized window or you have to wait for it. What actually seems to be going on, conceptually at least, is that there is a 1Mhz signal clock aligned for proper RAM access an the job is to transition the CPU onto that. So it either has to pause for a 2Mhz cycle or it doesn't but either way it's then on a 1Mhz clock. If I had known more about the BBC and its stretched cycles at the time, I hopefully would not have made the error. As per my extended exposition, I'm still a little annoyed about it.
'Flying Experience' and 'Select Level (1 to 6)' are Mode 1; the six numbered options are Mode 4 with busy wait palette changes. So that's all eight colours on a 320px width display. I think possibly a developer found himself with an opportunity for amusement.
The actual game also has a 1/6 mode split as pictured, but just the one.
Also, a quick bit of extra detail on my ElectrEm comments: rather than applying a cost of two or three 2Mhz cycle lengths when a 1Mhz access follows a 2Mhz access depending on phase, it applies a cost of 1 or 2, owing to my misreading of the EAUG. At the time I understood memory to be pumping out as though an 8-bit 2Mhz device, so either you hit the 2Mhz-sized window or you have to wait for it. What actually seems to be going on, conceptually at least, is that there is a 1Mhz signal clock aligned for proper RAM access an the job is to transition the CPU onto that. So it either has to pause for a 2Mhz cycle or it doesn't but either way it's then on a 1Mhz clock. If I had known more about the BBC and its stretched cycles at the time, I hopefully would not have made the error. As per my extended exposition, I'm still a little annoyed about it.
Re: Electron to BBC Conversions
Ooh - I'd not seen the Service Manual before. That would have saved me a certain amount of reverse engineering earlier in this thread!
It's curious that the divide-by-thirteen clock signal is an input to the ULA. I'd have thought that awkward clock divisions were exactly what a ULA was good at.
And yeah, it seems the Elecrton's memory subsystem is, indeed, horrible. I guess getting it out the door at a cost point was much more important to Acorn than performance at the time it was being designed. /-8
It's curious that the divide-by-thirteen clock signal is an input to the ULA. I'd have thought that awkward clock divisions were exactly what a ULA was good at.
And yeah, it seems the Elecrton's memory subsystem is, indeed, horrible. I guess getting it out the door at a cost point was much more important to Acorn than performance at the time it was being designed. /-8
-
- Posts: 2611
- Joined: Sat Apr 03, 2010 1:54 pm
- Location: Nottingham
- Contact:
Re: Electron to BBC Conversions
I don't suppose anyone has been able to convert Flightpath 737 to work on the BBC B from its original Electron version?
Mick.
Mick.