> @cgracey said:
> Man, that's like microfiche. If you can get 200 rows in landscape, you could get 320 rows in portrait mode. Seeing lots of code at once is like high-def for your programming mind.
Its a neat feat to be sure, but when you’re part of the trifocal crowd, all you see is fuzz! That “font6” (8x6 font) is tiny.
When Rogloh adds-in portrait mode (nudge-nudge), this is gonna be amazing. I mean, at last count he had 4 bytes of space left, right?
@rogloh Ok! We have data... and I lied... and an oddity!
Data:
The P2 clock speed for what the driver calls "1920x1200" in DVI mode is 308 mhz.
I Lied:
Turns out the monitor is a 28 inch, not a 24 inch. My bad. It's an ASUS PB287Q (4K UHD (3840 x 2160) display with 1ms response time and 60Hz refresh rate. I'm still looking for a specific list of the various modes/refresh capabilities, but the spec says "24 ~99 KHz (H) / 30 ~75 Hz (V)".
The Oddity:
By my math, 1920x1200 using the "font6" font file should give us 240 cols by 200 rows of text. But see the picture. I can fit *210* rows on-screen. It isn't scrolling. It all fits.
@JRoark This makes no sense to me yet so I'm trying to get my head around how it can be working at all...
Firstly if the P2 clock speed is 308MHz with DVI as you have selected 1920x1200 mode, the dot clock is automatically set to 1/10 of this value, making it just 30.8MHz!
Here's the timing for that mode
wuxga_timing ' experimental 1920x1200@60Hz for Dell 2405FPW at 77*4 MHz YMMV
long CLK308MHz
long 308000000
'_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
' 1 bit 7 bits 8 bits 8 bits 8 bits
long (SYNC_POS<<31) | ( 16<<24) | ( 16<<16) | (128<<8 ) |(1920/8)
'_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
' 1 bit 8 bits 3 bits 9 bits 11 bits
long (SYNC_NEG<<31) | ( 8<<23) | ( 3<<20) | ( 23<<11) | 1200
long 2<<8
long 0
long 0 ' reserved for CFRQ parameter
The CLK308MHz PLL value I use for the 1920x1200 mode is this constant which looks right:
Horizontally that is 1920+128+16+16 = 2080 total pixels with blanking and sync, and vertically it is 1200+8+3+23 = 1234 scan lines.
The horizontal frequency is then 30.8M/2080 = 14.808kHz and vertical is 14.808/1234 = 12Hz!
Your monitor seems particularly frequency tolerant to accept these numbers outside its own spec, but ok, maybe some can really sync down that low.
The weirdest thing though are these 10 extra rows (at different font sizes!) in some resolutions. This is not some extra constant number of scan lines being added, it is a constant number of rows. My driver counts scan lines, not rows and will deliver a given number of visible scan lines as specified in the timing structure above. Font data for rows are generated by an incmod operation that wraps at the height of the font. The only way I could imagine it could deliver 10 extra rows on the screen is if it skips a total of 10*fontheight scan lines in various places throughout the frame to make room for these extra rows but this should be noticeable if that is happening. Maybe there is a bug in the code that doing this, I'll have to look but I've never seen it before and I am now working with slightly newer code too. I wonder if you monitor's scaler is doing something strange at these ultra low refresh frequencies and the scrolling extra rows are somehow blended into the frame displayed?
Roger
P.S. What does your "EGA" column signify in your table above?
Whoops. That “EGA” column should read “Analog”. Sorry about that. I had the DVI breakout starting on pin 8 going to the high-end HDMI monitor, and the VGA Analog breakout starting on pin 48 going to a really ancient Dell and Sony monitor. I’d just uncomment one line of code in your demo to switch between the two. It was very slick how your driver handled that.
And yes. this whole thing with working at all is a really odd duck. I dont see how it works either. As you are seeing, one of my great claims to fame is being able to break things in odd, novel, expensive and infuriating ways. Some day I want write a book called “Warranties I have blown”.
On a serious note, I’ll make you an offer: I’ll ship you the monitor, cable. and manuals for 30 days. You get to noodle and play to your hearts content. In return you could “engine-ify” your code so it basically stands alone as a class and has a few simple interface methods. I *really* want to have something stable and capable “in the can” that my minions can access trivially from FlexBASIC. If you’re interested, PM me!
There's an Asus HD monitor here if thats worth a try. Its not one of the 5 regular monitors we use for testing, but we could try it. Its HD rather than 4k
Don't worry about it. If this is a real bug in the code we can resolve it eventually. I have a feeling it might be a side effect of your monitor. A real DVI mode is not meant to work so low. You've been able to get it to work much lower than normal on your own setup, and this may have introduced some weird side effects.
I will test 1920x1200 later today with different font sizes on my Dell (in VGA mode) and see if I find any mismatch with the row count for various font heights.
@JRoark I tried out with my latest code using an analog VGA output (the original driver code at 1920x1200 over DVI won't sync on my Dell DVI monitor due to refresh rate being too low, unlike your ASUS monitor which can take it).
The results at 1920x1200 were these:
6 scan line font : 200 visible rows
8 scan line CGA font : 150 visible rows
14 scan line EGA font : ~86 visible rows
16 scan line VGA font : 75 visible rows
Here's a couple of photos of the 6 line font at the top left and bottom left of the screen... I just print the row number on each row in this simple loop...my screenbuf is an array of words 240x200 sized.
repeat x from 0 to 199
word[@screenbuf][x*240+3] := $20
word[@screenbuf][x*240+2] := x//10 + $30
word[@screenbuf][x*240+1] := (x//100)/10 + $30
word[@screenbuf][x*240+0] := x/100 + $30
I am thinking the issue you found must be particular to your setup. It doesn't appear to be an issue in the driver, certainly with VGA. DVI shares the same text loop and so must generate the same output but just over a different physical interface.
Update:
Also you didn't indicate this in your list of changes above but be sure to also edit the number of font scan lines in the region when you change the font. E.g., below you would change the value 16 parameter to the new font height if you used a different font. If you get this wrong, the row count could be affected, though I can't see how it would always be 10 extra rows as you observed.
Rogloh, that's very neat! Could you display some source code in that font, instead of dense data, so that we could get a feel for what it would be like to edit code on the chip, with 200 lines visible?
Chip, here are a couple of photos with both an 8 line font and a 6 line font and your SPIN interpreter code + row numbers on the side. Apologies for the poor lighting and picture clarity, it is night here so I couldn't take a nice shot, but hopefully it would give you the idea of what it can look like. Only half the potential screen width is being used here too.
Actually a portrait 8x8 font and display orientation would work better for coding and is doable if you just rotate the font's pixels and manage the screen positions differently. It could give you a 150x240 screen size which could be nice for SW development if you can use a nice 8x8 crisp font for coding. The pixel clarity in real life is a lot better than the photos below on my Dell monitor. It's really hi-res.
You know what you can do with that second-half of the screen? Show the next 150 lines of source code. Yeah!!!! This is really exciting to me, because it's opening a big door out the PC world, into one where we can make things just how we'd like.
That being a fork of the funscii font (itself a fork of unscii) with the P1 charset. But with the source, you can export any set of 256 characters (the full font set has all of PETSCII's funky graphics characters, many international characters and a lot more available, both in 8x8 and 8x16)
That being a fork of the funscii font (itself a fork of unscii) with the P1 charset. But with the source, you can export any set of 256 characters (the full font set has all of PETSCII's funky graphics characters, many international characters and a lot more available, both in 8x8 and 8x16)
Being able to express simple schematics in 8-bit characters is really nice! Great way to document in software how to hook something up.
I've long wanted to convert all whitespace longer than two spaces to a two-byte combo of 'whitespacestart' + 'numberofspaces'. 'Whitespacestart' can be some never-otherwise-used character, while 'numberofspaces' could be $40..$7E, or something. This could be used within editors and be stored the same way in files.
Yeah tabs were not implemented in my hacked up SPIN2 printing code yet, only BS, CR & LF are there so it needs further work. I'll try to add that too for the next release.
You know what you can do with that second-half of the screen? Show the next 150 lines of source code. Yeah!!!! This is really exciting to me, because it's opening a big door out the PC world, into one where we can make things just how we'd like.
Yep. Once we have that SPIN2 compiler running on the P2 itself you should be easily able to make a nice PASM/SPIN2 standalone system using either VGA or DVI monitors, or even TVs, with USB keyboards.
On widescreen monitors you could use that extra screen real estate to show a whole range of stuff, like debugger state, logs, other files, pin states, memory views, logic analyser, command lines, etc etc. A textual IDE could be made up (TUI) a bit like the old Turbo Pascal/Turbo debugger stuff we used back in the day. If the external flash device also became a file system it could enable you to host this dev environment and the code your are working on, though flash will obviously wear out eventually if you write to it too many times, and the standalone model may not suit developers who would want their PCs to do the editing. The SD card is another option at least on the P2-EVAL board to host edited source files.
The main problems I'm seeing with standalone development:
- P2 has no protection against the to-be-debugged program messing up the entire machine (except those last 16K of hub RAM that can be protected. Can a full IDE (or well, the debugger part) fit there? I guess it has to, anyways, since the program itself will often need all available RAM? idk)
- If you're developing something that needs a display and a keyboard, sharing that with the IDE might be troublesome to work out (and having two monitor/keyboard sets defeats the whole point).
- If you're developing something that uses the SD card, you're running the risk of messing up the source code. And when you're not backing it up often (which would require a second SD card (and slot!) or a PC), that could be annoying.
OTOH, it'd be of great use for embedded control stuff that has a monitor/keyboard attached, anyways. (Ideally built into a machine that is too big to move near a PC...) If there's a problem or a new feature is needed, just do some key combo and the code pops up. Just like ye olde BASIC interpreters.
Yes, I've been thinking that it would be good to use one P2 as the host and another P2 as the target. Just need connections to RESn/P63/P62. Of course, a PC can make those three connections, as well, and there's no need to replicate monitors, keyboard, mouse, storage.
Yes, I've been thinking that it would be good to use one P2 as the host and another P2 as the target. Just need connections to RESn/P63/P62. Of course, a PC can make those three connections, as well, and there's no need to replicate monitors, keyboard, mouse, storage.
From a STEM standpoint where there is very little budget, being able to turn a group of learners loose with nothing more than a mouse, keyboard and monitor could really be a game-changer. VGA monitors are easily scavenged, as are mice and keyboards. Even if you cant do a full-blown dev effort with an embedded compiler, it would still be useful as a teaching tool.
Yes, I've been thinking that it would be good to use one P2 as the host and another P2 as the target. Just need connections to RESn/P63/P62. Of course, a PC can make those three connections, as well, and there's no need to replicate monitors, keyboard, mouse, storage.
From a STEM standpoint where there is very little budget, being able to turn a group of learners loose with nothing more than a mouse, keyboard and monitor could really be a game-changer. VGA monitors are easily scavenged, as are mice and keyboards. Even if you cant do a full-blown dev effort with an embedded compiler, it would still be useful as a teaching tool.
Yeah, you could definitely get rid of the PC and all its conundrums. I think if people had the experience of programming right on the P2, where things were ultra responsive and no funny stuff was going on, they would really have a good time. It would keep their minds on the work at hand. No television-like distractions.
Chip: What is particularly interesting from the impromptu discussions I've had with educators can really be boiled down to five things:
1). Cost. No need for expensive PC hardware
2). No real possibility of student abuse. Sure, the kids can break it, but in the case of the P2-ES kit (#64000), there isn't ANYTHING on that board that cant be cheaply fixed inside of 30 minutes with on-campus resources. Short of physically breaking the PCB, a one-time hardware investment will last them essentially forever.
3). Immediacy. The whole ethic of being able to "make-the-change-and-see-it-work-right-now" is a clear winner for student engagement. Classes are short. The dev process needs to really rock along... and so would!
4). No "toolchains" or expensive software/licenses.
5). Library support. There needs to be access to simple code (ala Obex, Github) samples and ideally, entire lessons.
6). Portability. If each student could carry their ENTIRE dev environment on a thumbdrive (etc), you could play the palace.
The IT support guys were VERY enthusiastic about having a solution that didn't need internet access and didnt come with all of the attendant risks, potholes and tech support issues. They'd rather spend their (paltry) budgets on dealing with "real" problems... not rebuilding machines that got inadvertantly zorched because someone plugged a BadUSB thumbdrive into an open port. The thought of most problems being completely cured by hitting the reset button on the Prop2 made them all warm and fuzzy.
Oops. Thread drift. Sorry Roger. Chip made me do it!
JRoark, I like that idea a lot! It makes sense to me, too. When we've done workshops, you wouldn't believe what double-digit percentage of the time goes to just getting people operational with their PC's, involving drivers, internet, hookups, etc. It's a deep mire. We could be totally free of that.
What @"Peter Jakacki" has done is a darned amazing HMI and borderline full-blown os. > @rogloh said:
> @JRoark I tried out with my latest code using an analog VGA output (the original driver code at 1920x1200 over DVI won't sync on my Dell DVI monitor due to refresh rate being too low, unlike your ASUS monitor which can take it).
>
> The results at 1920x1200 were these:
>
> 6 scan line font : 200 visible rows
> 8 scan line CGA font : 150 visible rows
> 14 scan line EGA font : ~86 visible rows
> 16 scan line VGA font : 75 visible rows
>
> Here's a couple of photos of the 6 line font at the top left and bottom left of the screen... I just print the row number on each row in this simple loop...my screenbuf is an array of words 240x200 sized. repeat x from 0 to 199 word[@screenbuf][x*240+3] := $20 word[@screenbuf][x*240+2] := x//10 + $30 word[@screenbuf][x*240+1] := (x//100)/10 + $30 word[@screenbuf][x*240+0] := x/100 + $30
>
> I am thinking the issue you found must be particular to your setup. It doesn't appear to be an issue in the driver, certainly with VGA. DVI shares the same text loop and so must generate the same output but just over a different physical interface.
>
> Update:
> Also you didn't indicate this in your list of changes above but be sure to also edit the number of font scan lines in the region when you change the font. E.g., below you would change the value 16 parameter to the new font height if you used a different font. If you get this wrong, the row count could be affected, though I can't see how it would always be 10 extra rows as you observed. vid.initRegion(@region, VID#TEXT, 0, VID#FLASH_TEXT, @vgapalette, @fontvga16, 16, @screenbuf, @display)
@rogloh The more I play with this, the more I tend to believe that you are correct, ie, that this “Extra lines” effect is an artifact of this particular monitor. I tried another one today (a 2k TV screen actually) and there are no extra rows. Very fishy!
Also correct: I was indeed changing the font lines value in the InitRegion() call as is proper. Somehow that it didnt make it into my post.
@rogloh The more I play with this, the more I tend to believe that you are correct, ie, that this “Extra lines” effect is an artifact of this particular monitor. I tried another one today (a 2k TV screen actually) and there are no extra rows. Very fishy!
What I am thinking might be happening here in your setup @JRoark is that the driver is scrolling the screen up when you draw more than a complete screen of text (ie. more than 200 lines with a 6 line font), and your monitor is somehow getting confused and is merging this extra data into the displayed screen with older data from prior frames. This might be happening because the refresh rate is so low, outside its rated operational range. Maybe the screen has even frozen up after a few frames so if you continue to draw to it changing the text at the top and bottom rows in memory (row 1 and your extra row 210) it might even behave differently.
I know this effect doesn't happen at regular 60Hz refresh rates in my setup and it is interesting that your extra row effect only shows up at the much higher resolutions, where the vertical and horizontal refresh rates would be at their lower values. I think all display bets are off once refresh rate timing goes outside a monitor's spec.
Just for a laugh I rotated the 8x8 font and displayed the SPIN2 code in a portrait mode at 150 columns x 240 rows using 1920x1200 with VGA from the P2. Here's what it looks like now...it's very readable.
It's not part of any driver, so it's just some really hard coded testing stuff used so I could just see what it looked like for Chip, but here were some snippets anyway you can always try to play with or make robust...
repeat y from 0 to 239
word[@screenbuf][149*240+y] := y/100 + $30
word[@screenbuf][148*240+y] := (y//100)/10 + $30
word[@screenbuf][147*240+y] := y//10 + $30
word[@screenbuf][146*240+y] := $20
z:=145
repeat while byte[@spincode][x++] <> 10 ' line feed
w := byte[@spincode][x-1]
if (w > 31)
word[@screenbuf][z*240 + y]:=w
if (w == 9)
repeat 8 - ((145-z) & 7)
word[@screenbuf][z*240 + y]:=32
z--
else
z--
repeat while z > 0
word[@screenbuf][z*240+y] := 32
z--
...
VAR
byte temp[8]
PUB rotatefont(fontbuf) | char, x, y
repeat char from 0 to 255
repeat x from 0 to 7
temp[x] := 0
repeat y from 0 to 7
if byte[fontbuf][char + (y<<8)] & (1<<(7-x)) <> 0
temp[x] += (1<<y)
repeat x from 0 to 7
byte[fontbuf][char + (x<<8)] := temp[x]
No worries. This actually pushes the new P2 video driver pretty hard to generate mono text. The P2 is running at 308MHz and generating 154 Mpixels/second for 1920x1200 in a single COG. At this rate this particular text mode doesn't have time for processing any attributes (you need a 3x clock for that), so in a text editor application any inverse text capability (eg. for text selection with a mouse/cursor) would probably have to fit using the upper 128 characters of the font. But that is of course still doable.
Slightly lower resolutions, or lower frame rates like full HD with interlacing can drop the pixel clock and allow attributes like inverse/flash etc, or even colour once the P2 clock : pixel clock hits the 5x ratio. I have interlaced font output supported so you don't have to sacrifice vertical text resolution when you use 1080i, and you can retain 1080 pixels of height for text.
Update: The other way to reduce the processing need for very high resolution text output from the P2 could be to allocate multiple render COGs to generate text into their own line buffers and then you could clock the P2 as low as the pixel rate (in transparent mode). If you have lots of free COGs that's another way to go and it can also add other text features/colour styles etc.
Comments
> Man, that's like microfiche. If you can get 200 rows in landscape, you could get 320 rows in portrait mode. Seeing lots of code at once is like high-def for your programming mind.
Its a neat feat to be sure, but when you’re part of the trifocal crowd, all you see is fuzz! That “font6” (8x6 font) is tiny.
When Rogloh adds-in portrait mode (nudge-nudge), this is gonna be amazing. I mean, at last count he had 4 bytes of space left, right?
@JRoark This makes no sense to me yet so I'm trying to get my head around how it can be working at all...
Firstly if the P2 clock speed is 308MHz with DVI as you have selected 1920x1200 mode, the dot clock is automatically set to 1/10 of this value, making it just 30.8MHz!
Here's the timing for that mode
wuxga_timing ' experimental 1920x1200@60Hz for Dell 2405FPW at 77*4 MHz YMMV long CLK308MHz long 308000000 '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns ' 1 bit 7 bits 8 bits 8 bits 8 bits long (SYNC_POS<<31) | ( 16<<24) | ( 16<<16) | (128<<8 ) |(1920/8) '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible ' 1 bit 8 bits 3 bits 9 bits 11 bits long (SYNC_NEG<<31) | ( 8<<23) | ( 3<<20) | ( 23<<11) | 1200 long 2<<8 long 0 long 0 ' reserved for CFRQ parameterThe CLK308MHz PLL value I use for the 1920x1200 mode is this constant which looks right:
CLK308MHz = %1_000100_0001001100_1111_10_00 '(20MHz/5) * 77/1 = 308 MHz
Horizontally that is 1920+128+16+16 = 2080 total pixels with blanking and sync, and vertically it is 1200+8+3+23 = 1234 scan lines.
The horizontal frequency is then 30.8M/2080 = 14.808kHz and vertical is 14.808/1234 = 12Hz!
Your monitor seems particularly frequency tolerant to accept these numbers outside its own spec, but ok, maybe some can really sync down that low.
The weirdest thing though are these 10 extra rows (at different font sizes!) in some resolutions. This is not some extra constant number of scan lines being added, it is a constant number of rows. My driver counts scan lines, not rows and will deliver a given number of visible scan lines as specified in the timing structure above. Font data for rows are generated by an incmod operation that wraps at the height of the font. The only way I could imagine it could deliver 10 extra rows on the screen is if it skips a total of 10*fontheight scan lines in various places throughout the frame to make room for these extra rows but this should be noticeable if that is happening. Maybe there is a bug in the code that doing this, I'll have to look but I've never seen it before and I am now working with slightly newer code too. I wonder if you monitor's scaler is doing something strange at these ultra low refresh frequencies and the scrolling extra rows are somehow blended into the frame displayed?
Roger
P.S. What does your "EGA" column signify in your table above?
And yes. this whole thing with working at all is a really odd duck. I dont see how it works either. As you are seeing, one of my great claims to fame is being able to break things in odd, novel, expensive and infuriating ways. Some day I want write a book called “Warranties I have blown”.
On a serious note, I’ll make you an offer: I’ll ship you the monitor, cable. and manuals for 30 days. You get to noodle and play to your hearts content. In return you could “engine-ify” your code so it basically stands alone as a class and has a few simple interface methods. I *really* want to have something stable and capable “in the can” that my minions can access trivially from FlexBASIC. If you’re interested, PM me!
I will test 1920x1200 later today with different font sizes on my Dell (in VGA mode) and see if I find any mismatch with the row count for various font heights.
The results at 1920x1200 were these:
6 scan line font : 200 visible rows
8 scan line CGA font : 150 visible rows
14 scan line EGA font : ~86 visible rows
16 scan line VGA font : 75 visible rows
Here's a couple of photos of the 6 line font at the top left and bottom left of the screen... I just print the row number on each row in this simple loop...my screenbuf is an array of words 240x200 sized.
repeat x from 0 to 199 word[@screenbuf][x*240+3] := $20 word[@screenbuf][x*240+2] := x//10 + $30 word[@screenbuf][x*240+1] := (x//100)/10 + $30 word[@screenbuf][x*240+0] := x/100 + $30I am thinking the issue you found must be particular to your setup. It doesn't appear to be an issue in the driver, certainly with VGA. DVI shares the same text loop and so must generate the same output but just over a different physical interface.Update:
Also you didn't indicate this in your list of changes above but be sure to also edit the number of font scan lines in the region when you change the font. E.g., below you would change the value 16 parameter to the new font height if you used a different font. If you get this wrong, the row count could be affected, though I can't see how it would always be 10 extra rows as you observed.
Actually a portrait 8x8 font and display orientation would work better for coding and is doable if you just rotate the font's pixels and manage the screen positions differently. It could give you a 150x240 screen size which could be nice for SW development if you can use a nice 8x8 crisp font for coding. The pixel clarity in real life is a lot better than the photos below on my Dell monitor. It's really hi-res.
One thing, though... Your tabs aren't right. Do something like this:
if chr == tab repeat 8 - (current_column & 7) print($20) -or- if chr == tab current_column := (current_column | 7) + 1Those PASM code rows are so tight, like double-packed. Makes me imagine they take half the clocks to execute.
have you seen this? A ROM font compatibile 8x8 font
That being a fork of the funscii font (itself a fork of unscii) with the P1 charset. But with the source, you can export any set of 256 characters (the full font set has all of PETSCII's funky graphics characters, many international characters and a lot more available, both in 8x8 and 8x16)
Being able to express simple schematics in 8-bit characters is really nice! Great way to document in software how to hook something up.
I've long wanted to convert all whitespace longer than two spaces to a two-byte combo of 'whitespacestart' + 'numberofspaces'. 'Whitespacestart' can be some never-otherwise-used character, while 'numberofspaces' could be $40..$7E, or something. This could be used within editors and be stored the same way in files.
Yeah tabs were not implemented in my hacked up SPIN2 printing code yet, only BS, CR & LF are there so it needs further work. I'll try to add that too for the next release.
Yep. Once we have that SPIN2 compiler running on the P2 itself you should be easily able to make a nice PASM/SPIN2 standalone system using either VGA or DVI monitors, or even TVs, with USB keyboards.
On widescreen monitors you could use that extra screen real estate to show a whole range of stuff, like debugger state, logs, other files, pin states, memory views, logic analyser, command lines, etc etc. A textual IDE could be made up (TUI) a bit like the old Turbo Pascal/Turbo debugger stuff we used back in the day. If the external flash device also became a file system it could enable you to host this dev environment and the code your are working on, though flash will obviously wear out eventually if you write to it too many times, and the standalone model may not suit developers who would want their PCs to do the editing. The SD card is another option at least on the P2-EVAL board to host edited source files.
- P2 has no protection against the to-be-debugged program messing up the entire machine (except those last 16K of hub RAM that can be protected. Can a full IDE (or well, the debugger part) fit there? I guess it has to, anyways, since the program itself will often need all available RAM? idk)
- If you're developing something that needs a display and a keyboard, sharing that with the IDE might be troublesome to work out (and having two monitor/keyboard sets defeats the whole point).
- If you're developing something that uses the SD card, you're running the risk of messing up the source code. And when you're not backing it up often (which would require a second SD card (and slot!) or a PC), that could be annoying.
OTOH, it'd be of great use for embedded control stuff that has a monitor/keyboard attached, anyways. (Ideally built into a machine that is too big to move near a PC...) If there's a problem or a new feature is needed, just do some key combo and the code pops up. Just like ye olde BASIC interpreters.
From a STEM standpoint where there is very little budget, being able to turn a group of learners loose with nothing more than a mouse, keyboard and monitor could really be a game-changer. VGA monitors are easily scavenged, as are mice and keyboards. Even if you cant do a full-blown dev effort with an embedded compiler, it would still be useful as a teaching tool.
Yeah, you could definitely get rid of the PC and all its conundrums. I think if people had the experience of programming right on the P2, where things were ultra responsive and no funny stuff was going on, they would really have a good time. It would keep their minds on the work at hand. No television-like distractions.
1). Cost. No need for expensive PC hardware
2). No real possibility of student abuse. Sure, the kids can break it, but in the case of the P2-ES kit (#64000), there isn't ANYTHING on that board that cant be cheaply fixed inside of 30 minutes with on-campus resources. Short of physically breaking the PCB, a one-time hardware investment will last them essentially forever.
3). Immediacy. The whole ethic of being able to "make-the-change-and-see-it-work-right-now" is a clear winner for student engagement. Classes are short. The dev process needs to really rock along... and so would!
4). No "toolchains" or expensive software/licenses.
5). Library support. There needs to be access to simple code (ala Obex, Github) samples and ideally, entire lessons.
6). Portability. If each student could carry their ENTIRE dev environment on a thumbdrive (etc), you could play the palace.
The IT support guys were VERY enthusiastic about having a solution that didn't need internet access and didnt come with all of the attendant risks, potholes and tech support issues. They'd rather spend their (paltry) budgets on dealing with "real" problems... not rebuilding machines that got inadvertantly zorched because someone plugged a BadUSB thumbdrive into an open port. The thought of most problems being completely cured by hitting the reset button on the Prop2 made them all warm and fuzzy.
Oops. Thread drift. Sorry Roger. Chip made me do it!
> @JRoark I tried out with my latest code using an analog VGA output (the original driver code at 1920x1200 over DVI won't sync on my Dell DVI monitor due to refresh rate being too low, unlike your ASUS monitor which can take it).
>
> The results at 1920x1200 were these:
>
> 6 scan line font : 200 visible rows
> 8 scan line CGA font : 150 visible rows
> 14 scan line EGA font : ~86 visible rows
> 16 scan line VGA font : 75 visible rows
>
> Here's a couple of photos of the 6 line font at the top left and bottom left of the screen... I just print the row number on each row in this simple loop...my screenbuf is an array of words 240x200 sized. repeat x from 0 to 199 word[@screenbuf][x*240+3] := $20 word[@screenbuf][x*240+2] := x//10 + $30 word[@screenbuf][x*240+1] := (x//100)/10 + $30 word[@screenbuf][x*240+0] := x/100 + $30
>
> I am thinking the issue you found must be particular to your setup. It doesn't appear to be an issue in the driver, certainly with VGA. DVI shares the same text loop and so must generate the same output but just over a different physical interface.
>
> Update:
> Also you didn't indicate this in your list of changes above but be sure to also edit the number of font scan lines in the region when you change the font. E.g., below you would change the value 16 parameter to the new font height if you used a different font. If you get this wrong, the row count could be affected, though I can't see how it would always be 10 extra rows as you observed. vid.initRegion(@region, VID#TEXT, 0, VID#FLASH_TEXT, @vgapalette, @fontvga16, 16, @screenbuf, @display)
@rogloh The more I play with this, the more I tend to believe that you are correct, ie, that this “Extra lines” effect is an artifact of this particular monitor. I tried another one today (a 2k TV screen actually) and there are no extra rows. Very fishy!
Also correct: I was indeed changing the font lines value in the InitRegion() call as is proper. Somehow that it didnt make it into my post.
I know this effect doesn't happen at regular 60Hz refresh rates in my setup and it is interesting that your extra row effect only shows up at the much higher resolutions, where the vertical and horizontal refresh rates would be at their lower values. I think all display bets are off once refresh rate timing goes outside a monitor's spec.
repeat y from 0 to 239 word[@screenbuf][149*240+y] := y/100 + $30 word[@screenbuf][148*240+y] := (y//100)/10 + $30 word[@screenbuf][147*240+y] := y//10 + $30 word[@screenbuf][146*240+y] := $20 z:=145 repeat while byte[@spincode][x++] <> 10 ' line feed w := byte[@spincode][x-1] if (w > 31) word[@screenbuf][z*240 + y]:=w if (w == 9) repeat 8 - ((145-z) & 7) word[@screenbuf][z*240 + y]:=32 z-- else z-- repeat while z > 0 word[@screenbuf][z*240+y] := 32 z-- ... VAR byte temp[8] PUB rotatefont(fontbuf) | char, x, y repeat char from 0 to 255 repeat x from 0 to 7 temp[x] := 0 repeat y from 0 to 7 if byte[fontbuf][char + (y<<8)] & (1<<(7-x)) <> 0 temp[x] += (1<<y) repeat x from 0 to 7 byte[fontbuf][char + (x<<8)] := temp[x]Slightly lower resolutions, or lower frame rates like full HD with interlacing can drop the pixel clock and allow attributes like inverse/flash etc, or even colour once the P2 clock : pixel clock hits the 5x ratio. I have interlaced font output supported so you don't have to sacrifice vertical text resolution when you use 1080i, and you can retain 1080 pixels of height for text.
Update: The other way to reduce the processing need for very high resolution text output from the P2 could be to allocate multiple render COGs to generate text into their own line buffers and then you could clock the P2 as low as the pixel rate (in transparent mode). If you have lots of free COGs that's another way to go and it can also add other text features/colour styles etc.