xor xold xnew
xor yold ynew
and xold yold
add xold #1
-> zero: were equal
didn't realize, 1 xor 1 = 0 xor 0 = 0, so ok +1 is not needed.
But combining two 16 bit values to one 32 bit value may take more computing time and even more code space, so the pros and cons have to be carefully weighted. My gut feeling is keeping the variables separated is the better solution
For CMPX, if the WZ effect is specified, the Z flag is set (1) if Z was previously set
and Value1 equals Value2 + C (use WC and WZ on preceding CMP and CMPX instructions).
If the WC effect is specified, the C flag is set (1) if Value1 is less than Value2
(as multi-long values).
This would mean you would need to ensure the C flag is cleared.
TV with no VGA inputs just got me thinking about TFP410 DVI encoder and choice of palette...
Only problem there is that it uses a lot more pins...
This palette would need 24 pins for color (8 each for R, G, and Blue).
But, the Windows 16 color palette only needs 6 pins (2 each for R, G, and Blue).
Actually, I guess I'd need to figure out if I could use the streamer with 6 pins for color.
That might be a trick. Maybe I could tell it to use 24-bit color but only enable 6 of 24 pins for output...
TV with no VGA inputs just got me thinking about TFP410 DVI encoder and choice of palette...
Only problem there is that it uses a lot more pins...
That's part of why Chip put the color engine back in. We can do component, RGB, whatever.
I've setup various displays, and have an older world standard broadcast monitor for SD now too. (all the PAL / NTSC variants)
When I can get back to this, and understand how that color transform system works better, I intend to follow up on some formats. P2 has killer display support. And the landscape is fracturing some. An ideal setup is probably good analog support + an HDMI converter, with output tuned pixel perfect. It's gonna cover everybody and on almost all of those options, we get color management. One unified color space, drive what you got. The exception will be TTL displays, and nobody will care. Because TTL.
Component should sing on most HDTV sets, and it's capable of things like running luma at full resolution, color at some other one too. HDMI 4K does this, luma at the 4K color stays at current 1080 --ish.
One nice thing about it, lacking in VGA, is all the HDTV capable displays will continue to support a slow horizontal refresh, 15Khz. While this limits vertical resolution to under 500 pixels generally, it's a great 640, 720, 800 pixel x 400ish pixel display option. And it maps back to simple S-video / Composite for prototyping, capture, whatever.
and seems to have just 8 font files, with 8,10,12,16, and i & b suffix, guessing those are italic and Bold ?
They are quite small, being 1986 to 2907 bytes in size. Maybe that 1367, 2271 above is the raster in bytes, before the record headers are added ? ( Diff of a similar 619 & 636 bytes )
Missing from the list above look to be 14,20,24 sizes ?
Comments
Why not just
rdlong gx1, ##@xmouse rdlong gy1, ##@ymouse cmp gx1, CursorX wz if_nz jmp #GEMove cmp gy1, CursorY wz if_nz jmp #GEMove jmp #GEDone GEMove mov CursorX, gx1 mov CursorY, gy1 ' etc...xor yold ynew
and xold yold
add xold #1
-> zero: were equal
Shouldn't the AND be an OR instead?
or you could use ANYB like so
Do you need a 32bit value for the old mouse coordinates?
Put X in the upper word, Y in the lower word.
Do the same for the CursorX/Y values.
Then XOR OLD,NEW
If it's non-zero, then it changed.
But combining two 16 bit values to one 32 bit value may take more computing time and even more code space, so the pros and cons have to be carefully weighted. My gut feeling is keeping the variables separated is the better solution
I'm still deciding on this... Right now, it feels like we have nearly infinite memory space, so I'm just doing everything as longs.
If things get tight later, I might have to reconsider...
rdlong gx1,##@xmouse rdlong gy1,##@ymouse cmp gx1,CursorX wz,wc cmpx gy1,CursorY wz,wc if_e jmp #GEDoneIs there a problem though if both x and y change by 1?
Seems like won't work if gy1=CursorY+carry...
rdlong gx1,##@xmouse rdlong gy1,##@ymouse cmp gx1,CursorX wz if_z cmp gy1,CursorY wz if_z jmp #GEDoneAndy
That looks very straightforward.
This uses Z-AND in CMPX, but does C have any use?
I like this the most, so far. It's still very clear what's being tested, but avoids the extra branches that my version had.
Remove them from my example and all is well.
The docs just say:
"Compare S with carry to D unsigned. If the wc is specified then the carry flag is set if there is an overflow"
All the add/sub/cmp instructions which end in the letter X do two special things which aid in >32-bit extended integer operations:
1) They incorporate the C flag as input.
2) Rather than set Z according to result=0, Z gets AND'd with result=0.
This would mean you would need to ensure the C flag is cleared.
Therefore Ariba's solution is the way to go.
Made a better paint demo.
This is bit of distraction from goal though...
Need to add buttons next...
PS: In case anybody actually tries it, the right mouse button clears the drawing area...
PS2: I was thinking about connecting this to my new TV, but realized it doesn't have any VGA inputs... VGAs days may be numbered...
Only problem there is that it uses a lot more pins...
This palette would need 24 pins for color (8 each for R, G, and Blue).
But, the Windows 16 color palette only needs 6 pins (2 each for R, G, and Blue).
Actually, I guess I'd need to figure out if I could use the streamer with 6 pins for color.
That might be a trick. Maybe I could tell it to use 24-bit color but only enable 6 of 24 pins for output...
That's part of why Chip put the color engine back in. We can do component, RGB, whatever.
I've setup various displays, and have an older world standard broadcast monitor for SD now too. (all the PAL / NTSC variants)
When I can get back to this, and understand how that color transform system works better, I intend to follow up on some formats. P2 has killer display support. And the landscape is fracturing some. An ideal setup is probably good analog support + an HDMI converter, with output tuned pixel perfect. It's gonna cover everybody and on almost all of those options, we get color management. One unified color space, drive what you got. The exception will be TTL displays, and nobody will care. Because TTL.
Component should sing on most HDTV sets, and it's capable of things like running luma at full resolution, color at some other one too. HDMI 4K does this, luma at the 4K color stays at current 1080 --ish.
One nice thing about it, lacking in VGA, is all the HDTV capable displays will continue to support a slow horizontal refresh, 15Khz. While this limits vertical resolution to under 500 pixels generally, it's a great 640, 720, 800 pixel x 400ish pixel display option. And it maps back to simple S-video / Composite for prototyping, capture, whatever.
Ready to move on now.
I think it's good now.
BTW: My 4yo just tried it out. His first time with a mouse. Got it right away...
Also has variable pitch and wide font support
Very Impressive...
I had a quick scan of Project Oberon docs, and I can find a 1024x768 display spec, but not much hard info on the fonts themselves...
Some info here.. source code
http://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Fonts.Mod.txt
has comment
(* raster sizes: Syntax8 1367, Syntax10 1628, Syntax12 1688, Syntax14 1843, Syntax14b 1983,
Syntax16 2271, Syntax20 3034, Syntac24 4274, Syntax24b 4302 *)
This link says Tools, Fonts & Libraries
http://www.projectoberon.net/zip/apptools.zip
and seems to have just 8 font files, with 8,10,12,16, and i & b suffix, guessing those are italic and Bold ?
They are quite small, being 1986 to 2907 bytes in size. Maybe that 1367, 2271 above is the raster in bytes, before the record headers are added ? ( Diff of a similar 619 & 636 bytes )
Missing from the list above look to be 14,20,24 sizes ?
With the source code and the PDF
http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf
there might be enough info to be able to read (or convert) those font files ?
Addit: google also finds this, a Mac port, dated Jul 31 2016
https://itunes.apple.com/us/app/oberon-workstation/id1057155516?mt=12
I'm moved by this, takes me back to Commodore and Atari, and being able to create graphics on screen. Great work, all of you!