I've been playing with adding in VGA into TAQOZ which I compile for testing out of P2 RAM and it seems to be working well so far. I'm fixing up any bugs and adding new features with a view to seeing what I can cram into the new ROM. I am able view load bmp files easily and I would like to add vga text as well although I know that the font table won't fit. I really wish we could have a 32k ROM but maybe I will design TAQOZ so that it automatically extends itself if it finds support in the Flash or SD. Then again, it is just as easy for it to load a new version anyway.
So on my list of to do's I need to add functionality to create a boot file on Flash and/or SD. The new P2D2 has a small support micro onboard and besides boot control and temperature monitoring it also provides reference timing so the P2 can work out what frequency it is running at.
Another item for my wish list is if only the P2 could read it's own clock input directly so that before it is applied as the system clock we could check automatically that it was working and what the frequency is and whether it is a straight oscillator or a crystal etc. Maybe a high value resistor from XI to one of the boot I/O might be sufficient given that even with the RC filtering that happens we could use smartpins to detect reduced levels.
Thanks for that info on the fonts guys. If we did manage to get about 2k free I could build it in although the VGA would really only work if we had an external clock source.
Thanks for that info on the fonts guys. If we did manage to get about 2k free I could build it in although the VGA would really only work if we had an external clock source.
Playing with the VGA at 200MHz clock.
That's neat, Peter. Were those files on an SD card?
Yes, the video is a bit rough but you can see I did a DIR from TAQOZ and I cheated a little bit in defining TIGER as : TIGER $22440 VIEW ; etc but that is in anticipation of having TAQOZ searching the SD card automatically for when it doesn't find the word in the dictionary. So TIGER would fail a dictionary search and then would scan the file directory and find a BMP with that name which would then associate the BMP with VIEW, all seamlessly!
The SD read routine is still a bit slow because I had a problem with multiple block reads and just reverted quickly to a sector at a time version.
Yes, the video is a bit rough but you can see I did a DIR from TAQOZ and I cheated a little bit in defining TIGER as : TIGER $22440 VIEW ; etc but that is in anticipation of having TAQOZ searching the SD card automatically for when it doesn't find the word in the dictionary. So TIGER would fail a dictionary search and then would scan the file directory and find a BMP with that name which would then associate the BMP with VIEW, all seamlessly!
The SD read routine is still a bit slow because I had a problem with multiple block reads and just reverted quickly to a sector at a time version.
Nice.
Ideas for out-of-the-box usefulness are interesting. I wonder what kinds of functions could sell a bunch of chips/boards without the customer being very technical.
I think everything today that permits you to simply view a file is also routing all your activity to the corp/gov data collectors.
Another item for my wish list is if only the P2 could read it's own clock input directly so that before it is applied as the system clock we could check automatically that it was working and what the frequency is and whether it is a straight oscillator or a crystal etc. Maybe a high value resistor from XI to one of the boot I/O might be sufficient given that even with the RC filtering that happens we could use smartpins to detect reduced levels.
The lack of a missing clock detector, is a weakness in P2.
Not sure how you could fix that, in verilog ?
If a copy of the Xtal signal could be polled in a register, code in HFOSC mode could check it was at least not stuck H or L over many samples.
You would need to rely on HFOSC being unstable enough to not lock to Xtal in. Maybe HFOSC code can enable PLL and sweep during the test ?
Or, an edge-triggered S_R cell could clear from HFOSC and trigger from Xtal pin edge ?
Of course, that is still short of a limp-home mode, but an external watchdog could re-enter the HFOSC code, which then decides to not enable the missing Xtal ?
Peter, have you got any advice on what to do with the non-CS/CLK/DI/DO pins on an SD card? Do some need to be pulled high or low, or can they be wired high or low? We just need the minimal setup for our board. Thanks.
Peter, have you got any advice on what to do with the non-CS/CLK/DI/DO pins on an SD card? Do some need to be pulled high or low, or can they be wired high or low? We just need the minimal setup for our board. Thanks.
In my experience I find that no pull-ups are needed, especially the chip select. All the really old information on the net would have all these pull-ups, even on the unused pins, but the fact that they totally missed the point about not having a pull-up on the CS indicated to me that they didn't really read or know the spec, they were playing it "safe" from their point of view. Even on serial Flash I only use the one pull-up, which of course for these chips is on the CS since they don't have a built-in pull-up like SD cards do
Peter, have you got any advice on what to do with the non-CS/CLK/DI/DO pins on an SD card? Do some need to be pulled high or low, or can they be wired high or low? We just need the minimal setup for our board. Thanks.
In my experience I find that no pull-ups are needed, especially the chip select. All the really old information on the net would have all these pull-ups, even on the unused pins, but the fact that they totally missed the point about not having a pull-up on the CS indicated to me that they didn't really read or know the spec, they were playing it "safe" from their point of view. Even on serial Flash I only use the one pull-up, which of course for these chips is on the CS since they don't have a built-in pull-up like SD cards do
Yes, no pull-ups are required for an SD card. I had used a pull-up on /CS due to old habits, plus I used a 4x10K which I used on RST, SCL, SCK, CS on my P1 boards. But I would not put one on CS to the SD these days.
BTW IIRC don't forget P59 requires ~10pF to GND for the current P2 silicon.
Here a a few improvements to TAQOZ and VGA capabilities, mainly in reading the bmp file and also in the vga driver. The vga driver's palette and intensity are updated every vsynch.
Also, I've fixed the camera in place for a clear view.
When getting my P2D2 running, Peter helped me do some TAQOZ testing. I thought I would document those commands here to make it easy for others not familiar with TAQOZ to get started.
From power-up/restart, enter the following three characters
"< {esc}"
without quotes, where {esc} is the esc character. Note the space after the "<" is required. Don't wait too long after power up to enter this.
The "< " sets the autobaud in ROM for the serial, and the <esc> forces a jump to TAQOZ. Replace the <esc> with Ctrl-D to jump to the Monitor.
Here are some TAQOZ commands. Note some require the additional TAQOZ code stored in flash.
Ctrl-W List TAQOZ words
Ctrl-D Jumps to the ROM Monitor/Debugger
lsio <cr> List all I/O pin values
61 pin 10 hz <cr> outputs a 10Hz signal on P61 (the P2D2 board has a LED on P61)
61 blink <cr> outputs a 1Hz signal on P61
61 pin mute <cr> turns off the output to P61
10 for crlf ."Hello World"next <cr> prints 10 times
0 $100 dump <cr> dump memory 0-$100
0 $100 dumpw <cr> dump word
0 $100 dumpa <cr> dump ascii
0 $100 dumpaw <cr> dump ascii word ??
0 $100 dumpl <cr> dump long
0 qd <cr> quick dump
0 sf qd <cr> quick dump serial flash
.sf <cr> print flash serial numbers
sfsid .l <cr> print flash serial number
sfjid .l <cr> print flash jedec number
0 pin 115200 txd sets up serial txd on P0
$55 wypin outputs char($55) on P0
fibos <cr> prints the fibonacci results
The following commands change the oscillator (requires the Flash TAQOZ) and reset the serial baud
Ctrl-R Restore from flash (requires additional TAQOZ code to be stored in flash
Ctrl-W List TAQOZ words
hyper 115200 conbaud <cr> 340 MHz
turbo 115200 conbaud <cr> 250 MHz
cruise 115200 conbaud <cr> 180 MHz
slow 115200 conbaud <cr> 40 MHz
If you are using an ANSI terminal such as TeraTerm etc
Alt-i Alt-s e <cr> resets TeraTerm com port and P2D2
Ctrl-R Restore from flash (requires additional TAQOZ code to be stored in flash
erscn clear screen but leaves cursor at same position
home erscn clear screen and home
: cls home erscn ; <cr> defines new TAQOZ word cls that does home erscn
I thought I'd have a play with some image processing and one of the routines I use a lot in my photo editors is gamma correction. So I'd thought I'd have some fun and just did a quick and simple gamma correction which simply looks for a threshold and if a value is below that it will apply a correction lighter or darker. The whole routine takes 86 bytes and it is already very useful just as it is and only takes about 3ms to correct a bmp palette.
--- simple gamma routine
: GAMMA ( gamma* gamma/ thresh< -- )
_th C! gam/ C! gam* C!
PALETTE $400 ADO
I @ RGB> ( split into components )
3 FOR DUP _th C@ < IF gam* C@ gam/ C@ */ THEN ROT NEXT
>RGB I ! ( recombine rgb and update )
4 +LOOP DROP
;
Just added VGA text on VGA graphics handling although nothing has yet been optimized. I can however direct TAQOZ output to the VGA monitor and draw and view etc on the screen at the same time interactively.
Up to 106x60 text which of course can be any color or textured. Next thing to try is converting a BREAKOUT game for this and then adding a wave player.
You are having way too darn much fun, while I struggle with "doesn't have a chip yet" envy! My FPGA board will not fire up. Gonna have to sort out why.
Well done Peter. Well earned too. Nice work.
(And I will be fine. The boards with Rev A chips will be here soon enough...)
Wow, Peter! I think you've nearly got a computer there.
That scrolling could be made really fast by using SETQ+RDLONG, followed by SETQ+WRLONG, to move big chunks at a time.
When I get USB HID working and then add in Ethernet then I might be close(r).
Thanks for the tip about SETQ RDLONG but doesn't that need to read into cog memory first? I'm still using a REPS loop that moves bytes around but obviously if I did the same for longs it would run faster.
' (RCMOVE) ( src dst cnt -- ) Copy bytes from src to dst for cnt bytes starting from the ends (in reverse)
pRCMOVE modcz _set,0 wc 'modc $0F wc ' set carry for decrementing (always cleared by PUSH)
' (CMOVE) ( src dst cnt -- ) Copy cnt bytes from src to dst address
CMOVE rep @.end,tos
rdbyte R0,tos2 ' read source byte
sumc tos2,#1 ' inc or dec depending upon carry
wrbyte R0,tos1 ' write destination byte
sumc tos1,#1 ' inc or dec depending upon carry!!
.end jmp #DROP3
Wow, Peter! I think you've nearly got a computer there.
That scrolling could be made really fast by using SETQ+RDLONG, followed by SETQ+WRLONG, to move big chunks at a time.
When I get USB HID working and then add in Ethernet then I might be close(r).
Thanks for the tip about SETQ RDLONG but doesn't that need to read into cog memory first? I'm still using a REPS loop that moves bytes around but obviously if I did the same for longs it would run faster.
' (RCMOVE) ( src dst cnt -- ) Copy bytes from src to dst for cnt bytes starting from the ends (in reverse)
pRCMOVE modcz _set,0 wc 'modc $0F wc ' set carry for decrementing (always cleared by PUSH)
' (CMOVE) ( src dst cnt -- ) Copy cnt bytes from src to dst address
CMOVE rep @.end,tos
rdbyte R0,tos2 ' read source byte
sumc tos2,#1 ' inc or dec depending upon carry
wrbyte R0,tos1 ' write destination byte
sumc tos1,#1 ' inc or dec depending upon carry!!
.end jmp #DROP3
Read and write 32-long blocks. It will be >100x faster.
Read and write 32-long blocks. It will be >100x faster.
I used the upper 128 longs in LUT memory and found that it ran about 43 times faster for 300k memory. Should it be faster?
TAQOZ# LAP $3.0000 DUP 310000 CMOVE LAP .LAP 7,517,772 cycles = 30,071,088ns @250,000,000Hz ok
TAQOZ# LAP $3.0000 DUP 310000 4/ LMOVE LAP .LAP 174,820 cycles = 699,280ns @250,000,000Hz ok
' LMOVE ( src dst longs -- ) ' preset for 128 long chunks
LMOVE setq2 #$80-1
rdlong $180,tos+2
setq2 #$80-1
wrlong $180,tos+1
add tos+2,L200
add tos+1,L200
sub tos,#$80 wc
if_nc jmp #LMOVE
jmp #DROP3
L200 long $200
Will TAQOZ include a Windowing System in the next re-spin?
Sure, if we have a larger ROM
But no, TAQOZ is useful as it is in 12k of the 16k ROM. But you can can have a larger version sitting in Flash or SD to load as you want, just as I am doing now. I am looking at implementing GUI windowing.
Will TAQOZ include a Windowing System in the next re-spin?
Sure, if we have a larger ROM
But no, TAQOZ is useful as it is in 12k of the 16k ROM. But you can can have a larger version sitting in Flash or SD to load as you want, just as I am doing now. I am looking at implementing GUI windowing.
Right now, we are using Ray's SD booter, right? Could it be integrated into TAQOS, so that its subroutines become available in Forth? Or, have you got the equivalent code in TAQOS, already? I mean, is there any functional redundancy, at this point? Or, can making this TAQOS-compatible expand the Forth, while still providing SD boot?
Will TAQOZ include a Windowing System in the next re-spin?
Sure, if we have a larger ROM
But no, TAQOZ is useful as it is in 12k of the 16k ROM. But you can can have a larger version sitting in Flash or SD to load as you want, just as I am doing now. I am looking at implementing GUI windowing.
Right now, we are using Ray's SD booter, right? Could it be integrated into TAQOS, so that its subroutines become available in Forth? Or, have you got the equivalent code in TAQOS, already? I mean, is there any functional redundancy, at this point? Or, can making this TAQOS-compatible expand the Forth, while still providing SD boot?
Please merge them or use just TAQOZ. It'd be great if TAQOZ bytecode could be loaded out of the MBR. This would allow any combination of manually specifying which file to load instead of loading the default file (e.g. based on hardware present), reading some filesystem other than FAT (e.g. ext4 or something exotic or custom), or finding the partition from some partition table format other than MBR (e.g. GPT), without having to worry about support for other filesystems or partition table types in ROM. Of course, leave FAT and MBR support (but all through TAQOZ) in ROM to make things easy in the normal case, but add this to make it possible to replace parts of the boot process with custom parts.
You would write the MBR from TAQOZ just like any other forth word, and then tell it to write that word to the MBR.
Comments
So on my list of to do's I need to add functionality to create a boot file on Flash and/or SD. The new P2D2 has a small support micro onboard and besides boot control and temperature monitoring it also provides reference timing so the P2 can work out what frequency it is running at.
Another item for my wish list is if only the P2 could read it's own clock input directly so that before it is applied as the system clock we could check automatically that it was working and what the frequency is and whether it is a straight oscillator or a crystal etc. Maybe a high value resistor from XI to one of the boot I/O might be sufficient given that even with the RC filtering that happens we could use smartpins to detect reduced levels.
https://graphicdesign.stackexchange.com/questions/91478/a-font-thats-readable-with-a-5px-height/91523
At least one of those packs 2 characters into 5 bytes!
That yields a font table of only 320 bytes!
That, on a 640x480 screen means... over 80 columns x over 60 columns.
Playing with the VGA at 200MHz clock.
That's neat, Peter. Were those files on an SD card?
The SD read routine is still a bit slow because I had a problem with multiple block reads and just reverted quickly to a sector at a time version.
Nice.
Ideas for out-of-the-box usefulness are interesting. I wonder what kinds of functions could sell a bunch of chips/boards without the customer being very technical.
I think everything today that permits you to simply view a file is also routing all your activity to the corp/gov data collectors.
The lack of a missing clock detector, is a weakness in P2.
Not sure how you could fix that, in verilog ?
If a copy of the Xtal signal could be polled in a register, code in HFOSC mode could check it was at least not stuck H or L over many samples.
You would need to rely on HFOSC being unstable enough to not lock to Xtal in. Maybe HFOSC code can enable PLL and sweep during the test ?
Or, an edge-triggered S_R cell could clear from HFOSC and trigger from Xtal pin edge ?
Of course, that is still short of a limp-home mode, but an external watchdog could re-enter the HFOSC code, which then decides to not enable the missing Xtal ?
In my experience I find that no pull-ups are needed, especially the chip select. All the really old information on the net would have all these pull-ups, even on the unused pins, but the fact that they totally missed the point about not having a pull-up on the CS indicated to me that they didn't really read or know the spec, they were playing it "safe" from their point of view. Even on serial Flash I only use the one pull-up, which of course for these chips is on the CS since they don't have a built-in pull-up like SD cards do
Thanks, Peter. This will keep things simple.
BTW IIRC don't forget P59 requires ~10pF to GND for the current P2 silicon.
Also, I've fixed the camera in place for a clear view.
When getting my P2D2 running, Peter helped me do some TAQOZ testing. I thought I would document those commands here to make it easy for others not familiar with TAQOZ to get started.
From power-up/restart, enter the following three characters
"< {esc}"
without quotes, where {esc} is the esc character. Note the space after the "<" is required. Don't wait too long after power up to enter this.
The "< " sets the autobaud in ROM for the serial, and the <esc> forces a jump to TAQOZ. Replace the <esc> with Ctrl-D to jump to the Monitor.
Here are some TAQOZ commands. Note some require the additional TAQOZ code stored in flash.
Up to 106x60 text which of course can be any color or textured. Next thing to try is converting a BREAKOUT game for this and then adding a wave player.
You are having way too darn much fun, while I struggle with "doesn't have a chip yet" envy! My FPGA board will not fire up. Gonna have to sort out why.
Well done Peter. Well earned too. Nice work.
(And I will be fine. The boards with Rev A chips will be here soon enough...)
That scrolling could be made really fast by using SETQ+RDLONG, followed by SETQ+WRLONG, to move big chunks at a time.
When I get USB HID working and then add in Ethernet then I might be close(r).
Thanks for the tip about SETQ RDLONG but doesn't that need to read into cog memory first? I'm still using a REPS loop that moves bytes around but obviously if I did the same for longs it would run faster.
' (RCMOVE) ( src dst cnt -- ) Copy bytes from src to dst for cnt bytes starting from the ends (in reverse) pRCMOVE modcz _set,0 wc 'modc $0F wc ' set carry for decrementing (always cleared by PUSH) ' (CMOVE) ( src dst cnt -- ) Copy cnt bytes from src to dst address CMOVE rep @.end,tos rdbyte R0,tos2 ' read source byte sumc tos2,#1 ' inc or dec depending upon carry wrbyte R0,tos1 ' write destination byte sumc tos1,#1 ' inc or dec depending upon carry!! .end jmp #DROP3Read and write 32-long blocks. It will be >100x faster.
I used the upper 128 longs in LUT memory and found that it ran about 43 times faster for 300k memory. Should it be faster?
Hey, you are loading into the control registers at $1Fx. Better change that $180 base to $170.
Or is rdlut & wrlut required also?
You're right. I didn't notice the SETQ2.
It makes sense, afterall.
But no, TAQOZ is useful as it is in 12k of the 16k ROM. But you can can have a larger version sitting in Flash or SD to load as you want, just as I am doing now. I am looking at implementing GUI windowing.
Right now, we are using Ray's SD booter, right? Could it be integrated into TAQOS, so that its subroutines become available in Forth? Or, have you got the equivalent code in TAQOS, already? I mean, is there any functional redundancy, at this point? Or, can making this TAQOS-compatible expand the Forth, while still providing SD boot?
Please merge them or use just TAQOZ. It'd be great if TAQOZ bytecode could be loaded out of the MBR. This would allow any combination of manually specifying which file to load instead of loading the default file (e.g. based on hardware present), reading some filesystem other than FAT (e.g. ext4 or something exotic or custom), or finding the partition from some partition table format other than MBR (e.g. GPT), without having to worry about support for other filesystems or partition table types in ROM. Of course, leave FAT and MBR support (but all through TAQOZ) in ROM to make things easy in the normal case, but add this to make it possible to replace parts of the boot process with custom parts.
You would write the MBR from TAQOZ just like any other forth word, and then tell it to write that word to the MBR.