The Nascom had 1 character per uS regardless if they were in blanking. This left 48 visible per line, but an offset of 64 beween columns. Of the 16 rows they had a strange idea of putting the last one at the top of the screen before the first one, hence all those setable syncronous counters in the video chain. It would have made no diference if the "Fixed Title" row was the first one in video ram and the scrolling software was altered.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby Seckshund said...
The Nascom had 1 character per uS regardless if they were in blanking. This left 48 visible per line, but an offset of 64 beween columns. Of the 16 rows they had a strange idea of putting the last one at the top of the screen before the first one, hence all those setable syncronous counters in the video chain. It would have made no diference if the "Fixed Title" row was the first one in video ram and the scrolling software was altered.
Well, the discussion here is not too closely related to the Nascom, though I may try to make a VGA driver for it once I get the 80x40 VGA with color going.
If they had made a clever design, you should have been able to set the video output start address by a port write. The buffer would always wrap at the $0bff, but you could have let the frame begin on any row. That way scrolling in either direction can be done by just one port write and clearing out one line. But no, they missed the point and instead decided to spend a few extra chips for no good reason
I tried both my usual SD cards (256MB & 512MB Integrals) and they always gave mount failures, on FAT16 or FAT32. I have just tried a 2GB Sandisk and it mounts and gets to the "Select a file to load ..." bit ok. All three run on the same hardware ok on CP/M.
Hey Ho.
ADDIT
I have tried some old SD and even a MMC card and they work, as far as I can tell, as well as the Sandisk. They never worked on the old software and a Prop. The list of .NAS files comes up and the up/down cursor selects but after the appearance of the loading happening it just crashes back to monitor prompt. But the M$ stuff runs ok, so a whole lump of the long lost Nas is running for me.
Once again, thankyou very much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 4/29/2010 5:27:15 PM GMT
Toby Seckshund said...
I tried both my usual SD cards (256MB & 512MB Integrals) and they always gave mount failures, on FAT16 or FAT32. I have just tried a 2GB Sandisk and it mounts and gets to the "Select a file to load ..." bit ok. All three run on the same hardware ok on CP/M.
This is interesting! The code accessing the SD cards is absolutely the same for the Nascom and CP/M. The difference is just the number of cogs used and the keyboard and video code.
I have a "no name" 4GB SD card that doesn't work with the driver, and a SanDisk 1GB and a 2GB that both work.
Toby Seckshund said...
Hey Ho.
ADDIT
I have tried some old SD and even a MMC card and they work, as far as I can tell, as well as the Sandisk. They never worked on the old software and a Prop. The list of .NAS files comes up and the up/down cursor selects but after the appearance of the loading happening it just crashes back to monitor prompt. But the M$ stuff runs ok, so a whole lump of the long lost Nas is running for me.
Once again, thankyou very much.
It crashes back to the monitor prompt?
No, that's no crash, that's expected behavior. I guess you're talking about the usual NASSYS-1 prompt?
Just type "E1000" for most of the programs to actually run.
Toby Seckshund said...
Thanks Pullmoll. I am trying to do bits and pieces between real work and demands from the Cheif Financial Controller of the household.
I never got to run BLS in the old days, so this will be a treat.
On VGA and everything will be just so perfect. I am genuinely greatful.
BLS Pascal is fun! You have to know (or guess) the commands as there is no help. Go to the editor with E. Write some code... Exit the editor with Ctrl+X. Compile it with C and run with R.
I may now try to create a VGA object for the Nascom, as I basically understood how to do it. I just need to figure the frequencies and PLL clocks per pixel required for an 384x240 display.
Re 'I may now try to create a VGA object for the Nascom, as I basically understood how to do it"
This sounds promising. 320x240 on a VGA. I'm looking forward to trying this out (I am suffering withdrawals - no hands-on propeller time for 48 hours. Only 5 hours to go...)
Toby Seckshund said...
Now,being an ungrateful, spoilt brat .....
I don't suppose that there is any way for the "files to load" list could sprout directories ????
I could try that at some point. I was thinking about it myself, because the SD's root directory is mighty crowded already. I would just have to remember the starting cluster of the currently selected directory and, in case of FAT16, distinguish between root directory and any other. I case of FAT32 it's even easier, because there also the root directory starts on a cluster chain.
I wondered if the new SD drivers and the Nascom would run on "Baby". It does wonderfully.
The slight shimmer on the pixel out would probably be improved if a stable start to each line could be had. The AVR VDUs I have played with in the past used an interupt out of a short sleep period, I wonder if that is possible on the one pin vid. (if it isn't my old monitor)
Addit
"Baby" wears overclocking quite well, and is happy at 14.319 * 8 but I haven't sussed out the right way to put those parameters into the code, yet. It seems to be a 17sec run on a 10000 for/next loop which was the same as the 4MHz N2 (I think) at 13.5 * 8.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 4/30/2010 9:09:30 PM GMT
Toby Seckshund said...
I wondered if the new SD drivers and the Nascom would run on "Baby". It does wonderfully.
The slight shimmer on the pixel out would probably be improved if a stable start to each line could be had. The AVR VDUs I have played with in the past used an interupt out of a short sleep period, I wonder if that is possible on the one pin vid. (if it isn't my old monitor)
Addit
"Baby" wears overclocking quite well, and is happy at 14.319 * 8 but I haven't sussed out the right way to put those parameters into the code, yet. It seems to be a 17sec run on a 10000 for/next loop which was the same as the 4MHz N2 (I think) at 13.5 * 8.
I don't know enough about video signal peculiarities to explain the shimmer on pixels. It may be due to slight shifts in the cycle counts per scanline, which can happen if the timing isn't perfectly synced to the hub access window.
FWIW doing anything with the VGA is much more difficult, because you have only half as many cycles available. The VGA 640x480 timing is exactly twice the clocks of NTSC-M, thus half the time. I'll have to do some more experimenting until I can do the VGA drivers for Nascom, TRS80 and M100.
Toby: If you are using the 1pinTV code, download the latest Debug1pin from the obex as there is a program to calculate the values included in the download.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Toby Seckshund said...
"Baby" wears overclocking quite well, and is happy at 14.319 * 8 but I haven't sussed out the right way to put those parameters into the code, yet. It seems to be a 17sec run on a 10000 for/next loop which was the same as the 4MHz N2 (I think) at 13.5 * 8.
Try the attached video.spin. Is the crystal really 14.319MHz or is it 14.318xxx? I extended the table to detect 14.319x8 now.
No, the Z80 is running at close to 2MHz with the 80MHz prop, not 4MHz. I can tell this because the TRS80 is slightly faster than the real thing, which ran at 1.774MHz. On your overclocked Baby it will be running close to 3MHz then. You can disable the #define BANKED_MEM, if you don't intend to use MP/M, this makes it yet a little faster.
Bad news: A VGA video object consisting of a video emitter cog and a pixel buffer generator cog + font exceeds the available hub RAM by 650 longs. This is mostly due to the required pixel buffer. I could save another 64 longs by reducing the font definition to 15 bytes per character, which OTOH complicates the addressing.
Well, anyway, it looks like unless I manage to do a _much_ smaller VGA video object - in one cog - I won't be able to add VGA to the Nascom emulation.
Right now I'm trying to convert Chip Gracey's VGA_HiRes_Text.spin to do 768x480, 2PLLs per pixel so I get 48 characters with 16 pixels and double-scan scanlines to get to 30 scanlines per character on the display. Since Chip's code is very, very sophisticated, I'm having my troubles integrating this.
If You use Crystal's from old VGA cards - correct value shall be --- 14.318.318.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
If You use Crystal's from old VGA cards - correct value shall be --- 14.318.318.
Regards
Thanks! That's what I meant to ask. I think Toby just specifies 14_319_000 while it should be the exact value, even if there is a tolerance of 1000. I'll change the video.spin object for the next update, as also the PLL frequency depends on the clock down to the one's digit.
Re the 2/4MHz "guestimations", that goes to show that the fond memories are rose tinted. I knew that a sort of bench mark for the Nas was 10000 for/next and 17 sec, that must have been with it on the 2MHz selection then. It was always much more reliable at half tilt.
The Xtal is a 14.31818, I just rounded it. I ended up sticking in a 13.5 but this is a SM·resonator.·I saw that the parameter was calculated against the clock figures and made a quick stab at a figure but getting the compiler to do any thing with it .... I wonder if given the overclocking if the VGA bits would become simpler, or would it still be beyond one cog ?
"Baby" is just a simplified, 2 latch DracBlade. Although the spare (second) serial pins could be used as page selects. I was trying to get CP/M into a *** packet, then Cluso went and put it into a match box.
The Prop is 80 miles away, and I am missing him/her dreadfully.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 5/2/2010 11:39:17 AM GMT
Toby Seckshund said...
The Xtal is a 14.31818, I just rounded it. I ended up sticking in a 13.5 but this is a SM resonator. I saw that the parameter was calculated against the clock figures and made a quick stab at a figure but getting the compiler to do any thing with it .... I wonder if given the overclocking if the VGA bits would become simpler, or would it still be beyond one cog ?
The setup of ifrqa depends on the exact value that is in clkfreq, thus you will have to specify 14_319_000 with the video.spin above, but I will change this to 14_318_318 resp. the resulting clock of 114_546_544 Hz for the next update. I guess I could also ignore the lower 3 or 6 digits, because the tolerance of most crystals is higher anyway.
It may be simpler to do VGA on an overclocked board, but since the default is 80MHz and I'd have to solder a new crystal on my DracBlade...
I'll be missing my Prop starting from Monday.. I finally have some contracted work to do, so there will be butter on my bread again soon [noparse]:)[/noparse]
I heavily modified Chip's VGA_HiRes_Text.spin and created a VGA_Nascom.spin from it. The net effect: it doesn't work anymore
What I tried to do is twofold: double the horizontal pixels by using a PLL per pixel factor of 2 and a frame size of 16. This part did work with the original driver at 768x480 after also changing the parts of the code that emitted "cols" instructions to only do "cols/2".
The next part was more difficult, and most probably is what's broken: instead of emitting 4 scanlines, I'm trying to emit 8 scanlines for each font quarter (it's an 8x16 font, so has 4 quarters of 8x4 pixels), repeating scanbuff once before rotating it to the next 8 pixels. I changed the code generator in the startup section and - just to be sure - wrote the plain code that should be generated at "org scancode". I suspected a bug in the generated code, but neither does work, so there's a bug elsewhere.
I think I had to change the cog interleave factor to 8 scanlines, because each cog is fetching 4 and should be displaying 8 scanlines. Thus I changed the initialization of the #vf and #vb values to +8/-8 instead of +4/-4 for the second cog. Also the fetching of the next scanbuff is split into 4 parts with a waitvid for 2 scanlines, so a total of 8 scanlines (it was 2 in parts with waitvid for 2 scanlines).
The issue of either 15 or 16 scanline font is not solved yet. To do 15 scanlines for a 768x480 display seems to be impossible, because this would break the cog interleaving - once it would work at all - so I would rather go with 512 scanlines and setup the timing to do an 800x600 resolution "underflow" with the 768x512.
I _think_ I have changed everything that needed a change to make the two cogs sync again, while obviously I didn't...
If someone is well acquainted with Chip's code and perhaps could take a look at what I did?
Juergen
Update: Fixed the broken font data and added a not-so-much-modified vga3.spin spinoff of Chip's code using 800x600 and double width characters, resulting in a 50x37 display with the 8x16 font. This is working. Now all I have to do is modify it so that each scanline is repeated once and the number of text rows is half as much. Then going to 768x512 by padding the front, back, top and bottom porches should work out.
Update2: Now I'm almost there. The scan line doubling is sort of working. The 4th quarter of the characters is wrong, though. It looks like it comes from another character code, so there is something modifying font_ptr before it should be modified.
Update3: YEAH! I got it working now. 768x512 centered in a 800x600 display with black borders, close to perfect pixels, i.e. no colour seams on the borders. This thing cost me 2 days of headaches and curses (no, not ncurses [noparse];)[/noparse]
Toby Seckshund said...
Just get on with the VGA and DIR bits then, you've got a whole afternoon left.
Implemented chdir() and it seems to work with FAT16. My camera accus are empty again and so I currently can't move files to the subdirectories to test if *.NAS loading works from there, but it should. FAT32 is also untested, while it should work as well. Please test + report v0.0.6
potatohead said...
That's a great looking display!
Yep! It is. I actually think I should create a semi-official derivative of VGA_HiRes_Text that uses a taller font, and perhaps the Latin 1 set instead of inverse attribute for bit #7. I also don't like the dense character rows too much, because especially after working for several hours there's just too much on the screen with 40 or even more rows on a display. Now 16 rows is a little too low, but 30 rows with a 8x16 font at 640x480 should be fine.
I just fired up 0.0.7. VGA working at 5MHz * 16 but didn't at 6MHz * 16 (out of range on monitor).
The 16 lines spread across 1440 pixels just shows how low res things had to be on the old 625 CRTs. Interesting that you chose just two levels of brightness, that would suit my 4 pin VGA efforts and allow for more unlatched pins to be available for memory/ I/O stuff.
Thankyou for all your effort (although the two house bunnies don't seem too impressed, they just slumped out and fell asleep)
ADDIT
The creation of a <games> folder shows up on the list but the cursor is frozen on the first line, and that one can't be selected. I tried it with FAT32 but that wouldn't load the roms. The initial file to load list seems to count the folder as a file.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 5/2/2010 7:25:45 PM GMT
Toby Seckshund said...
I just fired up 0.0.7. VGA working at 5MHz * 16 but didn't at 6MHz * 16 (out of range on monitor).
For 6x16MHz you should try to use another, lower pixel rate. 96MHz is 1,2 times 80MHz, so 50 / 1.2 = 41.6666. You could try with pr = 45 or better pr = 40 in vga.spin
The colour is hard coded in io.spin at the bottom. If you don't like the greenish display, you can e.g. use yellow on blue (%11110011_00000111). It's the usual color scheme RRGGBBxx_RRGGBBxx where xx is the sync and should always be 11.
For the directory functions: I have to check the various combinations myself. For me a directory NAS with all the *.NAS files worked - right now it's broken again, because I was trying to implement a match(direntry, mask) function where you could specify e.g. "*.NAS".. anyway, that is for the next update. I'm away now
On my 4 pin VGA I just left the syncs alone and used the two "blues", that left the other 4 pins which I planted the SD onto. The high blue (240 Ohm) was also pushed onto the red and green via more resistors and gave a white (ish) on a blue background.
I have tried an old 16MB SD on FAT16, but the same freeze happens.
And now SHE wants me to go and pretend I care !
Hey Ho.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Well, the discussion here is not too closely related to the Nascom, though I may try to make a VGA driver for it once I get the 80x40 VGA with color going.
If they had made a clever design, you should have been able to set the video output start address by a port write. The buffer would always wrap at the $0bff, but you could have let the frame begin on any row. That way scrolling in either direction can be done by just one port write and clearing out one line. But no, they missed the point and instead decided to spend a few extra chips for no good reason
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Hey Ho.
ADDIT
I have tried some old SD and even a MMC card and they work, as far as I can tell, as well as the Sandisk. They never worked on the old software and a Prop. The list of .NAS files comes up and the up/down cursor selects but after the appearance of the loading happening it just crashes back to monitor prompt. But the M$ stuff runs ok, so a whole lump of the long lost Nas is running for me.
Once again, thankyou very much.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 4/29/2010 5:27:15 PM GMT
This is interesting! The code accessing the SD cards is absolutely the same for the Nascom and CP/M. The difference is just the number of cogs used and the keyboard and video code.
I have a "no name" 4GB SD card that doesn't work with the driver, and a SanDisk 1GB and a 2GB that both work.
It crashes back to the monitor prompt?
No, that's no crash, that's expected behavior. I guess you're talking about the usual NASSYS-1 prompt?
Just type "E1000" for most of the programs to actually run.
Or type "EE000" to run the BASIC from ROM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I never got to run BLS in the old days, so this will be a treat.
On VGA and everything will be just so perfect. I am genuinely greatful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
BLS Pascal is fun! You have to know (or guess) the commands as there is no help. Go to the editor with E. Write some code... Exit the editor with Ctrl+X. Compile it with C and run with R.
I may now try to create a VGA object for the Nascom, as I basically understood how to do it. I just need to figure the frequencies and PLL clocks per pixel required for an 384x240 display.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
This sounds promising. 320x240 on a VGA. I'm looking forward to trying this out (I am suffering withdrawals - no hands-on propeller time for 48 hours. Only 5 hours to go...)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
http://www.nascomhomepage.com/pdf/BLSPAS.PDF.
Now,being an ungrateful, spoilt brat .....
I don't suppose that there is any way for the "files to load" list could sprout directories ????
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I could try that at some point. I was thinking about it myself, because the SD's root directory is mighty crowded already. I would just have to remember the starting cluster of the currently selected directory and, in case of FAT16, distinguish between root directory and any other. I case of FAT32 it's even easier, because there also the root directory starts on a cluster chain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
The slight shimmer on the pixel out would probably be improved if a stable start to each line could be had. The AVR VDUs I have played with in the past used an interupt out of a short sleep period, I wonder if that is possible on the one pin vid. (if it isn't my old monitor)
Addit
"Baby" wears overclocking quite well, and is happy at 14.319 * 8 but I haven't sussed out the right way to put those parameters into the code, yet. It seems to be a 17sec run on a 10000 for/next loop which was the same as the 4MHz N2 (I think) at 13.5 * 8.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 4/30/2010 9:09:30 PM GMT
I don't know enough about video signal peculiarities to explain the shimmer on pixels. It may be due to slight shifts in the cycle counts per scanline, which can happen if the timing isn't perfectly synced to the hub access window.
FWIW doing anything with the VGA is much more difficult, because you have only half as many cycles available. The VGA 640x480 timing is exactly twice the clocks of NTSC-M, thus half the time. I'll have to do some more experimenting until I can do the VGA drivers for Nascom, TRS80 and M100.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Try the attached video.spin. Is the crystal really 14.319MHz or is it 14.318xxx? I extended the table to detect 14.319x8 now.
No, the Z80 is running at close to 2MHz with the 80MHz prop, not 4MHz. I can tell this because the TRS80 is slightly faster than the real thing, which ran at 1.774MHz. On your overclocked Baby it will be running close to 3MHz then. You can disable the #define BANKED_MEM, if you don't intend to use MP/M, this makes it yet a little faster.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/2/2010 5:47:43 AM GMT
Well, anyway, it looks like unless I manage to do a _much_ smaller VGA video object - in one cog - I won't be able to add VGA to the Nascom emulation.
Right now I'm trying to convert Chip Gracey's VGA_HiRes_Text.spin to do 768x480, 2PLLs per pixel so I get 48 characters with 16 pixels and double-scan scanlines to get to 30 scanlines per character on the display. Since Chip's code is very, very sophisticated, I'm having my troubles integrating this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/2/2010 10:21:33 AM GMT
If You use Crystal's from old VGA cards - correct value shall be --- 14.318.318.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Thanks! That's what I meant to ask. I think Toby just specifies 14_319_000 while it should be the exact value, even if there is a tolerance of 1000. I'll change the video.spin object for the next update, as also the PLL frequency depends on the clock down to the one's digit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
The Xtal is a 14.31818, I just rounded it. I ended up sticking in a 13.5 but this is a SM·resonator.·I saw that the parameter was calculated against the clock figures and made a quick stab at a figure but getting the compiler to do any thing with it .... I wonder if given the overclocking if the VGA bits would become simpler, or would it still be beyond one cog ?
"Baby" is just a simplified, 2 latch DracBlade. Although the spare (second) serial pins could be used as page selects. I was trying to get CP/M into a *** packet, then Cluso went and put it into a match box.
The Prop is 80 miles away, and I am missing him/her dreadfully.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 5/2/2010 11:39:17 AM GMT
The setup of ifrqa depends on the exact value that is in clkfreq, thus you will have to specify 14_319_000 with the video.spin above, but I will change this to 14_318_318 resp. the resulting clock of 114_546_544 Hz for the next update. I guess I could also ignore the lower 3 or 6 digits, because the tolerance of most crystals is higher anyway.
It may be simpler to do VGA on an overclocked board, but since the default is 80MHz and I'd have to solder a new crystal on my DracBlade...
I'll be missing my Prop starting from Monday.. I finally have some contracted work to do, so there will be butter on my bread again soon [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/2/2010 11:47:09 AM GMT
Just get on with the VGA and DIR bits then, you've got a whole afternoon left.
(mind you, the speed you code at, that probably isn't a challenge!!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
What I tried to do is twofold: double the horizontal pixels by using a PLL per pixel factor of 2 and a frame size of 16. This part did work with the original driver at 768x480 after also changing the parts of the code that emitted "cols" instructions to only do "cols/2".
The next part was more difficult, and most probably is what's broken: instead of emitting 4 scanlines, I'm trying to emit 8 scanlines for each font quarter (it's an 8x16 font, so has 4 quarters of 8x4 pixels), repeating scanbuff once before rotating it to the next 8 pixels. I changed the code generator in the startup section and - just to be sure - wrote the plain code that should be generated at "org scancode". I suspected a bug in the generated code, but neither does work, so there's a bug elsewhere.
I think I had to change the cog interleave factor to 8 scanlines, because each cog is fetching 4 and should be displaying 8 scanlines. Thus I changed the initialization of the #vf and #vb values to +8/-8 instead of +4/-4 for the second cog. Also the fetching of the next scanbuff is split into 4 parts with a waitvid for 2 scanlines, so a total of 8 scanlines (it was 2 in parts with waitvid for 2 scanlines).
The issue of either 15 or 16 scanline font is not solved yet. To do 15 scanlines for a 768x480 display seems to be impossible, because this would break the cog interleaving - once it would work at all - so I would rather go with 512 scanlines and setup the timing to do an 800x600 resolution "underflow" with the 768x512.
I _think_ I have changed everything that needed a change to make the two cogs sync again, while obviously I didn't...
If someone is well acquainted with Chip's code and perhaps could take a look at what I did?
Juergen
Update: Fixed the broken font data and added a not-so-much-modified vga3.spin spinoff of Chip's code using 800x600 and double width characters, resulting in a 50x37 display with the 8x16 font. This is working. Now all I have to do is modify it so that each scanline is repeated once and the number of text rows is half as much. Then going to 768x512 by padding the front, back, top and bottom porches should work out.
Update2: Now I'm almost there. The scan line doubling is sort of working. The 4th quarter of the characters is wrong, though. It looks like it comes from another character code, so there is something modifying font_ptr before it should be modified.
Update3: YEAH! I got it working now. 768x512 centered in a 800x600 display with black borders, close to perfect pixels, i.e. no colour seams on the borders. This thing cost me 2 days of headaches and curses (no, not ncurses [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/2/2010 3:39:16 PM GMT
Implemented chdir() and it seems to work with FAT16. My camera accus are empty again and so I currently can't move files to the subdirectories to test if *.NAS loading works from there, but it should. FAT32 is also untested, while it should work as well. Please test + report v0.0.6
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
What next?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Yep! It is. I actually think I should create a semi-official derivative of VGA_HiRes_Text that uses a taller font, and perhaps the Latin 1 set instead of inverse attribute for bit #7. I also don't like the dense character rows too much, because especially after working for several hours there's just too much on the screen with 40 or even more rows on a display. Now 16 rows is a little too low, but 30 rows with a 8x16 font at 640x480 should be fine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Stop messing around and get me a program that lets me win the next 7 or 8 lotteries.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The 16 lines spread across 1440 pixels just shows how low res things had to be on the old 625 CRTs. Interesting that you chose just two levels of brightness, that would suit my 4 pin VGA efforts and allow for more unlatched pins to be available for memory/ I/O stuff.
Thankyou for all your effort (although the two house bunnies don't seem too impressed, they just slumped out and fell asleep)
ADDIT
The creation of a <games> folder shows up on the list but the cursor is frozen on the first line, and that one can't be selected. I tried it with FAT32 but that wouldn't load the roms. The initial file to load list seems to count the folder as a file.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 5/2/2010 7:25:45 PM GMT
For 6x16MHz you should try to use another, lower pixel rate. 96MHz is 1,2 times 80MHz, so 50 / 1.2 = 41.6666. You could try with pr = 45 or better pr = 40 in vga.spin
The colour is hard coded in io.spin at the bottom. If you don't like the greenish display, you can e.g. use yellow on blue (%11110011_00000111). It's the usual color scheme RRGGBBxx_RRGGBBxx where xx is the sync and should always be 11.
For the directory functions: I have to check the various combinations myself. For me a directory NAS with all the *.NAS files worked - right now it's broken again, because I was trying to implement a match(direntry, mask) function where you could specify e.g. "*.NAS".. anyway, that is for the next update. I'm away now
Cheers,
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/2/2010 7:30:43 PM GMT
I have tried an old 16MB SD on FAT16, but the same freeze happens.
And now SHE wants me to go and pretend I care !
Hey Ho.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Thank you, so much, for all the time that you have spent on this.
Alan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller