Electron Memory Contention

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: Electron Memory Contention

Post by paulb » Mon Sep 07, 2015 9:39 pm

1024MAK wrote:It is strange how Ferranti technology worked for Sinclair (ZX81 ULA, ZX Spectrum 16k/48k ULA, ZX Spectrum+ 128k ULA) but not allegedly for Acorn.
Or Amstrad, apparently. Of course, Steve Furber has more to say about this.

The first article puts the Amstrad gate array at 1200 gates, and I think the Electron one is 2000 gates. I don't know how many gates Sinclair was aiming at, although the book about that hardware probably has all the gory details.

User avatar
1024MAK
Posts: 8277
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Electron Memory Contention

Post by 1024MAK » Mon Sep 07, 2015 10:40 pm

It will have, but it's 20 miles away from me at the moment...

As Sinclair made alterations, so Ferranti produced a larger type ULA. So a ULA from an issue 1 or issue 2 Spectrum is a different ULA chip type compared to a ULA fitted to an issue 5 or issue 6 board.

And the ULA for the 128k Spectrum is even larger (it is in a bigger package due to having more input/output pins).

Mark

User avatar
davidb
Posts: 2290
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron Memory Contention

Post by davidb » Tue Sep 08, 2015 10:22 pm

Inspired by the palette switching thread and tricky's attempts to do something special for MODE 1, the discussion about the ULA's limitations in this thread got me thinking about a possible way to turn what appears to be a massive disadvantage into a peculiar Electron advantage. I ran the idea past paulb and it seemed like some experiments were in order. My thinking about the subject follows - corrections to any misunderstandings of CPU/ULA operation are welcome!

In Electron User, Roland Waddilove showed that, using interrupts and cycle counting, you could palette switch for each line of characters in MODE 6 and use the gaps to hide timing irregularities. In principle, you could do the same for any mode and even change the palette for each scanline, but you would need to be really good at timing. What you really need is some way of synchronizing palette changes with scanlines, like an interrupt handler, but the CPU/ULA contention provides something else we can use.

The service manual mentions that, in modes 0-3, the CPU is denied RAM access during the part of a scanline when the ULA is active. In fact, is is made to wait for RAM access. If we were cycle counting our way down the screen, we would have to take this into account, and without exact counting there's no way we can know which scanline we are on. However, there is a scenario where we can use this blocking behaviour to our advantage: when we run our code from ROM.

In ROM, the code is only blocked when we access RAM during the display period, when the ULA is active, so we can use this to ensure that we execute a particular piece of code when the display period is over. Starting from the top of the screen, we delay until we are sure that we are in the display period, then we access the RAM. The CPU stalls until the display period is over, but this guarantees that we will execute the next instruction at the first opportunity between scanlines. At this point, we change the palette then wait until the display period has begun, then we access RAM again. We are basically using RAM access as a way to synchronize display and execution.

So, that's the theory. Having made something work in Elkulator, the next step was to see if it worked on a real Electron. There's a minor difference, but the implementation seems basically sound. It's a testament to how good Elkulator is that you can use it to prototype code like this and see it working on a real Electron.

I'll start a thread in the Retro Software 8-bit Acorn Programming forum and put the code up later today or tomorrow. It may be useful for testing the limits of the FPGA Electron's ULA implementation. ;)
Attachments
Forskningsparken_Bridge_T-bane.png
Enhanced MODE 1 in Elkulator.
TV-demo.jpg
Enhanced MODE 1 on TV.

User avatar
1024MAK
Posts: 8277
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Electron Memory Contention

Post by 1024MAK » Tue Sep 08, 2015 10:28 pm

Hey, I like that =D> =D> =D>

Good idea :D

Mark

User avatar
daveejhitchins
Posts: 4631
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: Electron Memory Contention

Post by daveejhitchins » Wed Sep 09, 2015 7:42 am

=D> =D> Brilliant =D> =D>

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
hoglet
Posts: 7807
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Electron Memory Contention

Post by hoglet » Wed Sep 09, 2015 1:03 pm

davidb wrote:I'll start a thread in the Retro Software 8-bit Acorn Programming forum and put the code up later today or tomorrow. It may be useful for testing the limits of the FPGA Electron's ULA implementation. ;)
Yes please do post the code, so I can give it a try.

Dave

User avatar
davidb
Posts: 2290
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron Memory Contention

Post by davidb » Wed Sep 09, 2015 3:04 pm

I'll try to upload a ROM image tonight, and put the source code somewhere, too.

User avatar
davidb
Posts: 2290
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron Memory Contention

Post by davidb » Wed Sep 09, 2015 9:41 pm

Here's the ROM to play with. It contains the picture that I showed in my earlier message. I'll start thinking about what to do with the code and support tools.
Attachments
mode1-palette.rom.zip
MODE 1 enhanced palette ROM.
(7.99 KiB) Downloaded 42 times

User avatar
hoglet
Posts: 7807
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Electron Memory Contention

Post by hoglet » Wed Sep 09, 2015 11:00 pm

David,

Any clues as to how I start the ROM? It's not giving anything away with *HELP.

Dave

User avatar
davidb
Posts: 2290
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron Memory Contention

Post by davidb » Wed Sep 09, 2015 11:41 pm

:( It should start on boot-up, but *PAL might work.

Otherwise, I'll release a new version tomorrow that will respond to a star command.

User avatar
hoglet
Posts: 7807
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Electron Memory Contention

Post by hoglet » Thu Sep 10, 2015 7:14 am

Hi David,

I was able to get it to start in Elkulator (V1.0Win) using *FX 142,0

It's a bit jittery though.

I'll try it on ElectronFPGA later today.

Dave

User avatar
davidb
Posts: 2290
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron Memory Contention

Post by davidb » Thu Sep 10, 2015 8:09 am

There's sort of a 2Hz "twitch" to the display which makes it less than rock solid. I think the problem is that there's a period during which other code is being run by the OS and this sometimes delays start of the palette changing code.

I may look at ways to make this more robust later on.

User avatar
hoglet
Posts: 7807
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Electron Memory Contention

Post by hoglet » Thu Sep 10, 2015 1:53 pm

David,

I've been testing the Mode1Palette ROM you posted earlier.

Here's the result that I see in ElectrEm (Win32v06c) where it looks like the colours are not changing at the correct point:
mode1palette_electrem.PNG
The result in Elkulator (v1.0 Win) is very similar, but the twitching is much faster:
mode1palette_elkulator.PNG
In AtomFPGA, it's almost identical to Elkulator.

I'm not sure why I'm seeing different results to you, especially in Elkulator.

Any thoughts?

Dave

User avatar
davidb
Posts: 2290
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron Memory Contention

Post by davidb » Thu Sep 10, 2015 8:09 pm

Could it be the way that interrupts are simulated? I don't know enough about how Elkulator works but, as we saw with the BASIC timing test on real hardware, an Electron with Plus 1 attached performed differently to one without.

Enabling different items in the Disc menu in Elkulator tends to have an effect on the area covered by the palette switching.

I wouldn't worry about using this as a test for the FPGA Electron just yet. It looks like I need to nail down the behaviour on emulators before I could say what is definitive.

User avatar
oss003
Posts: 2851
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Electron Memory Contention

Post by oss003 » Thu Sep 10, 2015 9:01 pm

If you press a key during displaying the picture, the timing changes.

Greetings
Kees

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: Electron Memory Contention

Post by paulb » Thu Sep 10, 2015 10:15 pm

There are probably a few things that could help to stabilise the timing. That *FX call to "disable" the Plus 1 is, without looking it up, probably disabling various events related to the expansion hardware, and other events could be turned off, I suppose.

The ambitious thing, as I noted to davidb, is to do what Firetrack does and have some kind of way to calibrate the timing for the specific machine being used.

The really ambitious thing is to have some extra hardware to do palette tricks. :wink:

User avatar
davidb
Posts: 2290
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron Memory Contention

Post by davidb » Sat Sep 19, 2015 8:59 pm

I put the latest code for my palette switching tricks in a Mercurial repository. In the meantime, paulb has kindly agreed to let me distribute a few of his images (under the CC-BY-NC-SA 4.0 license) on a DFS disk to accompany the ROM image I've attached to this message.

Following hoglet's helpful advice about polling FE00 for changes, paulb figured out that the remaining cause of the jitter was the different between the two fields in the video output. If you compensate for the fact that one of them is longer than the other then you can get a steady picture. The code now tries to determine which field was previously shown and aims to ensure that it waits for the appropriate number of scanlines on the next one.

I think I've done as much as I want to on this for now. There are probably some improvements to be made, and I think it can be done in RAM with careful cycle counting, but I don't have the stamina for that at the moment.

Image
Attachments
palette-2015-09-19.png
One of Paul's sample images, as displayed in Elkulator.
palette-2015-09-19.png (11.27 KiB) Viewed 799 times
2015-09-19-palette.zip
ROM and DFS disk images.
(90.07 KiB) Downloaded 37 times

RobC
Posts: 2435
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: Electron Memory Contention

Post by RobC » Wed Sep 30, 2015 8:54 pm

I wonder whether it's possible to use this technique to modify the palette registers of a Chameleon every scan line?

I've got a routine for the Beeb that switches the Chameleon palette half-way down the screen to show 15 colours at once.

However, if you can accurately detect the start of a scanline on an Elk, in theory it could be possible to display 15 different colours + black on each scanline to give 3841 colours on screen at once!

User avatar
davidb
Posts: 2290
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron Memory Contention

Post by davidb » Wed Sep 30, 2015 11:41 pm

I don't know if it's possible on the Beeb. I guess tricky is the master of mode 1 scanlines on that machine. ;)

The trick here is to take advantage of a limitation of the Electron's ULA which I don't believe is present on the Beeb. I did some work on a clock cycle-based palette changer for the Electron but I think that the Beeb is a better candidate for that kind of thing. Maybe tricky's Frogger code can be adapted for the purpose.

User avatar
davidb
Posts: 2290
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron Memory Contention

Post by davidb » Thu Oct 01, 2015 1:30 pm

In a conversation with paulb about enhanced mode 1, he noted that one of the other uses of this trick would be to display 40 column text in 8 different colours, though with only 4 colours per line, of course. (However, you could simulate more with clever dithering...)

This made me wonder about the lack of a four colour mode 6 on the Electron. Just as mode 3 corresponds to mode 0 and mode 6 corresponds to mode 4, the machine certainly had the memory to handle a text-oriented mode 1 since it would have used less memory than mode 1 itself. Maybe that's something for a future enhanced Electron ULA. :)

ThomasHarte
Posts: 469
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Electron Memory Contention

Post by ThomasHarte » Fri Mar 11, 2016 12:04 am

I'm months late but I took a very quick look at this and ElectrEm is just off by one. I'm kicking myself right now.

ElectrEm applies the logic: if the 1Mhz cycle kicks off in line with the 1Mhz bus, it costs one cycle. If it doesn't align, it costs two. Of course the respective times should be two and three. It's consider adding an extra one on top of the two you know the access is going to take, not the one.

It presumably usually gets away with this because for the sort of software that is time critical the overwhelming majority of accesses are in RAM, and for consecutive accesses the pattern will be that the first access will always put you at a time out of alignment with the 1Mhz bus and then each from then on will cost two cycles.

ThomasHarte
Posts: 469
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Electron Memory Contention

Post by ThomasHarte » Fri Mar 11, 2016 2:52 pm

Further to this, I can confirm that an emulator:
  • providing 80000 cycles per frame, during which time it produces both an odd field and an even field;
  • that permits 2Mhz access to everything in the high 32 kb;
  • that normally permits 1Mhz access to RAM, with a potential extra 2Mhz cycle lost waiting for bus alignment; and
  • that also stops the CPU clock for any RAM accesses during the pixel part of lines with pixels in Modes 0–3.
... exactly reproduces the timing results of the original post.

I'm refreshing my memory as to Firetrack but the general gist of using the tape interrupts for timing is that the tape in output mode will shift data out as it's supposed to but will also trigger the data received interrupt if the outgoing pattern appears to contain a start/stop pair and the previous data received interrupt was sufficiently long ago. So who's shifting the register changes between input and output mode, but the interrupt logic appears to be freestanding.

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: Electron Memory Contention

Post by paulb » Fri Mar 11, 2016 3:50 pm

ThomasHarte wrote:Further to this, I can confirm that an emulator:
  • providing 80000 cycles per frame, during which time it produces both an odd field and an even field;
  • that permits 2Mhz access to everything in the high 32 kb;
  • that normally permits 1Mhz access to RAM, with a potential extra 2Mhz cycle lost waiting for bus alignment; and
  • that also stops the CPU clock for any RAM accesses during the pixel part of lines with pixels in Modes 0–3.
... exactly reproduces the timing results of the original post.
It was the fact that the CPU can't even access RAM at 2MHz outside the scanline periods that I found astonishing, given that the RAM is accessed alternately by the CPU and ULA in modes 4 to 6 and can be accessed at 2MHz by the ULA alone in the scanline periods in modes 0 to 3. I think I noted in this thread (or the other one showing some more advanced imagery) that Acorn threw away a lot of the inherent performance potential in the design by having the CPU confined in such a way. Such things are why I think it is interesting to quantify the complexity of the ULA and to figure out whether such decisions were strictly necessary. (As opposed to repeating the "it was hard to make the ULA" statement without really understanding whether such things would have made it any harder.)
ThomasHarte wrote: I'm refreshing my memory as to Firetrack but the general gist of using the tape interrupts for timing is that the tape in output mode will shift data out as it's supposed to but will also trigger the data received interrupt if the outgoing pattern appears to contain a start/stop pair and the previous data received interrupt was sufficiently long ago. So who's shifting the register changes between input and output mode, but the interrupt logic appears to be freestanding.
I think you mentioned the mechanism in the context of some other games, too.

ThomasHarte
Posts: 469
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Electron Memory Contention

Post by ThomasHarte » Fri Mar 11, 2016 4:40 pm

paulb wrote:It was the fact that the CPU can't even access RAM at 2MHz outside the scanline periods that I found astonishing,
I found that astonishing plus the fact that none of the emulators currently get Modes 0–3 correct plus the fact that ElectrEm gets everything wrong (because it was designed to get everything right, at least in the sense of 'no false assumptions'; coding errors and/or documentation misinterpretations are a separate issue).
paulb wrote:... given that the RAM is accessed alternately by the CPU and ULA in modes 4 to 6 and can be accessed at 2MHz by the ULA alone in the scanline periods in modes 0 to 3.
I also think the transitions to 1Mhz mode could surely be handled the ElectrEm way? If the first 1Mhz access following a 2Mhz access is on one of the RAM's accesses that is set aside for the CPU then you can proceed as though on the 2Mhz bus. Only if the attempted access is on the cycle that the CPU doesn't have access for should it need to wait. So the optimal physically achievable would be that a lucky 1Mhz access could occur at 2Mhz, rather than an unlucky one occurring at 1/1.5 Mhz.

Of course, this is back justification, trying to reason as to why I might have managed to get that wrong in the first place. Despite the documentation being very explicit.
paulb wrote:I think I noted in this thread (or the other one showing some more advanced imagery) that Acorn threw away a lot of the inherent performance potential in the design by having the CPU confined in such a way. Such things are why I think it is interesting to quantify the complexity of the ULA and to figure out whether such decisions were strictly necessary. (As opposed to repeating the "it was hard to make the ULA" statement without really understanding whether such things would have made it any harder.)
Agreed. The Electron manages contended RAM a lot better than the Atom, in automating it, but — sorry, all — I think worse than the directly competing ZX Spectrum.

... and you've probably read it already but The ZX Spectrum ULA: How to Design a Microcomputer is a really interesting book.
paulb wrote:
ThomasHarte wrote: I'm refreshing my memory as to Firetrack but the general gist of using the tape interrupts for timing is that ...
I think you mentioned the mechanism in the context of some other games, too.
Yes, although an otherwise discarded memory has resurfaced: I didn't know anything about Firetrack but it just worked when discovered. Conversely, Joe Blade — one of those using the tape system as a sort-of-VIA — didn't work properly for absolutely ages and required somebody else to notify me as to the correct behaviour. So probably Firetrack isn't relying on tape output to trigger data received full, though I guess it may be relying on tape output to trigger data sent as that's a direct and obvious intended use of the tape interrupts. Load a byte for output and get an interrupt when its been written out, a fixed amount of time later.

ThomasHarte
Posts: 469
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Electron Memory Contention

Post by ThomasHarte » Mon Mar 14, 2016 7:38 pm

Having briefly checked, Firetrack seems not to use the tape interrupts. Northern Star and Southern Belle definitely do, and fit the "output will obey an internal regular clock but will also trigger input interrupts" rule. Though in specific terms of matching it off with a theory of operation, I'm not completely sure how that matches with bit counting — for input there's impliedly some sort of counter so that you know when receive data is full following (i.e. at least 9 bits later after the last thing you thought was a stop bit). It seems that if I do anything with that counter while in output mode then I break Northern Star and Southern Belle. So possibly there's only one timer, counting either towards empty or towards full, and the other set of interrupts simply acts as though its timer were always in the state that permits the next interrupt. Or I've hit upon a lucky misemulation.

Joe Blade and the other Players titles I'm still trying to reacquaint myself with. There's a fixed timing kernel down near the bottom of the stack page which polls the interrupt register until it shows end of display is triggered. It then sets the palette to black and makes an indirect jump, presumably to the actual game logic, then polls the interrupt register until it shows receive data full, at which point it sets the palette to the current screen colours and repeats.

The thing I can't currently make sense of is that it appears to expect receive data full to be set even though the tape is in input mode and the tape motor isn't currently running. So, honestly, it's 80% odds on that there's some problem earlier in the emulation shell I'm using for diagnosis that's messing up the initial state. I'm investigating.

As to the original multicolour Mode 1 ROM placed above; I found that it behaved correctly under emulation if installed with the Plus 1 ROM, gave the colours-off view shared by both ElectrEm and Elkulator if installed in isolation without the Plus 1 ROM. I guess that result has already been realised, but I don't see it yet expressed.

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: Electron Memory Contention

Post by paulb » Mon Mar 14, 2016 8:21 pm

ThomasHarte wrote:As to the original multicolour Mode 1 ROM placed above; I found that it behaved correctly under emulation if installed with the Plus 1 ROM, gave the colours-off view shared by both ElectrEm and Elkulator if installed in isolation without the Plus 1 ROM. I guess that result has already been realised, but I don't see it yet expressed.
What about the ROM in this message?

ThomasHarte
Posts: 469
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Electron Memory Contention

Post by ThomasHarte » Mon Mar 14, 2016 10:37 pm

paulb wrote:
ThomasHarte wrote:As to the original multicolour Mode 1 ROM placed above; I found that it behaved correctly under emulation if installed with the Plus 1 ROM, gave the colours-off view shared by both ElectrEm and Elkulator if installed in isolation without the Plus 1 ROM. I guess that result has already been realised, but I don't see it yet expressed.
What about the ROM in this message?
It looks like the ROM contains only the *SHOW command and the disk has the files? That being the case, I was unable to load it on my current emulator code base as that doesn't have disk support yet; the current public ElectrEm in principle couldn't help since it appears that "Load ROM..." was never implemented, but I switched it out for the E00 ADFS that ElectrEm comes with and was able to proceed.

Some screen grabs are attached. As and when I have disk support in my new thing, I'll let you know. Also I think it'd be interesting to consider factoring in composite colour to your calculations. The PAL colour subcarrier runs at only 283.75 cycles per line — that's 177.34375 cycles during the Electron's active period. So if you're using the UHF modulator then you're getting nowhere near 320 pixels of resolution. Stipples will turn into unique colours.

I saw no difference between the Plus 1 ROM being present or absent.

Incidentally, what adjustment did you end up making for differing field lengths? As timed by interrupts, does one always look a line longer than the other?I've got my latest effort running 625 lines per frame, with the first 2.5 lines and an addition 2.5 from 312.5 being full sync to produce an interlace, the second field's first pixel being 39936 cycles after the first, and then it taking a further 40064 cycles to get back around to the first pixel of the first. Is that all your current understanding too?
Attachments
Screen Shot 2016-03-14 at 6.24.05 PM.png
Screen Shot 2016-03-14 at 6.24.35 PM.png
Screen Shot 2016-03-14 at 6.25.04 PM.png

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: Electron Memory Contention

Post by paulb » Mon Mar 14, 2016 10:53 pm

ThomasHarte wrote:Some screen grabs are attached. As and when I have disk support in my new thing, I'll let you know. Also I think it'd be interesting to consider factoring in composite colour to your calculations. The PAL colour subcarrier runs at only 283.75 cycles per line — that's 177.34375 cycles during the Electron's active period. So if you're using the UHF modulator then you're getting nowhere near 320 pixels of resolution. Stipples will turn into unique colours.
I guess one would expect that on television sets.
ThomasHarte wrote:I saw no difference between the Plus 1 ROM being present or absent.
I think davidb did do some things to disable certain interrupts, but all of this was tested in Elkulator and on a real Electron with Plus 1.
ThomasHarte wrote:Incidentally, what adjustment did you end up making for differing field lengths? As timed by interrupts, does one always look a line longer than the other?I've got my latest effort running 625 lines per frame, with the first 2.5 lines and an addition 2.5 from 312.5 being full sync to produce an interlace, the second field's first pixel being 39936 cycles after the first, and then it taking a further 40064 cycles to get back around to the first pixel of the first. Is that all your current understanding too?
I'd have to think about the question here, but my current understanding on the topic in general is found here. I'd never really thought too hard about the whole 312.5 line (625 / 2) thing but when davidb needed to synchronise with the start of display, he naturally discovered that one field is 312 lines and the next is 313 as far as the interrupt occurrences are concerned.

Meanwhile, hoglet's Electron FPGA needs to get this kind of thing right, which I think it mostly does.

ThomasHarte
Posts: 469
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Electron Memory Contention

Post by ThomasHarte » Mon Mar 14, 2016 11:19 pm

paulb wrote:I'd have to think about the question here, but my current understanding on the topic in general is found here. I'd never really thought too hard about the whole 312.5 line (625 / 2) thing but when davidb needed to synchronise with the start of display, he naturally discovered that one field is 312 lines and the next is 313 as far as the interrupt occurrences are concerned.

Meanwhile, hoglet's Electron FPGA needs to get this kind of thing right, which I think it mostly does.
There's not that much to it, I don't think — that being said, if you have code to detect the difference between an odd and even frame, whichever way around it might turn out that they're encoded — did you try outputting an interlaced image? I guess you'd likely need to use Mode 4 or 5 to be able to fit two fields in memory but you'd still be able to use extra colours because the only change would be switching the video address at end-of-display.

A bonus would be that, by using a real TV, we'd know which of the two fields is the longer for interrupt purposes, which I can't find any information on. Though it almost certainly should be the lower of the two, I think — the one that starts with a long sync that ends where a horizontal should be.

EDIT: prior to adjusting for different length fields, was the effect on real hardware anything like the animated GIF attached (but, because the capture software I used was sort of slow, a faster and more regular version)?
Interlace.gif

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: Electron Memory Contention

Post by paulb » Mon Mar 14, 2016 11:46 pm

ThomasHarte wrote:There's not that much to it, I don't think — that being said, if you have code to detect the difference between an odd and even frame, whichever way around it might turn out that they're encoded — did you try outputting an interlaced image? I guess you'd likely need to use Mode 4 or 5 to be able to fit two fields in memory but you'd still be able to use extra colours because the only change would be switching the video address at end-of-display.
If I understand you correctly here, what you're suggesting may be related to something someone else suggested, although that (generating colour mixes) may have been considered separately from attempting to put different colour information on alternate "625" lines (merely animating different screens quickly enough, regardless of where they end up precisely on the 625-line display) particularly as I think it was one of the US machines that was the subject of the technique (and so may have been using a different kind of display altogether).
ThomasHarte wrote:A bonus would be that, by using a real TV, we'd know which of the two fields is the longer for interrupt purposes, which I can't find any information on. Though it almost certainly should be the lower of the two, I think — the one that starts with a long sync that ends where a horizontal should be.
I don't know precisely what davidb did to deal with the different fields or even whether his code cares which one is which.
ThomasHarte wrote:EDIT: prior to adjusting for different length fields, was the effect on real hardware anything like the animated GIF attached (but, because the capture software I used was sort of slow, a faster and more regular version)?
No, I don't think so. One of davidb's objectives was to eliminate the kind of judder that the GIF exhibits.

Post Reply