Shop OBEX P1 Docs P2 Docs Learn Events
Nascom Z80 system — Parallax Forums

Nascom Z80 system

pullmollpullmoll Posts: 817
edited 2010-06-05 15:28 in Propeller 1
I looked around and remembered someone asking for it IIRC. Here's the first few bits of output from a Nascom emulation. Alpha code is attached.

You need the usual Propeller system with external RAM (XMM) and an SD card containing the ROM file(s). Tested on a DracBlade.
Currently just NASSYS1.ROM and BASIC.ROM is loaded. Other ROMs might be loaded later on.

The keyboard is kind of working now. I have no idea how to stop a running BASIC program! *lol* There is no Break key and Escape is actually Shift+Enter. The mapping of \ and _ is also very odd (shifted [noparse][[/noparse] and ]). Anyway, you can now type a BASIC program and try it.

v0.0.3
Fixed keyboard and UART. You need a terminal with 2400 baud, 7 bits, even parity, 1 stop bit.
Downloading through a terminal works with monitor commands X (enable UART) followed by L (load), then send a *.NAS file with your terminal program as text upload.
There is a faster method: put some *.NAS files on your SD card and use the file selection menu.
After loading a file to memory, use E (execute) start address (usually 1000).
A bunch of *.NAS files is in the subdirectory ./nascom/NAS.
v0.0.4
By default now use a reduced font height of 15 scanlines, resulting in a 384x240 display. Using all 16 scanlines pushes the TV to its limits, or beyond in case of NTSC.
Add support for sound on port #4 bit 0. I saw this being used in one BASIC game. Was there an agreement on which port/bit to use for sound output?
v0.0.5
Add support to load fonts. NASCOM.CHR is loaded from the SD card, if found. You can choose a *.NAS file loading from $0000-$0fff as a font file. One example is CGSARGON.NAS, which is a font for the SARGON13.NAS chess game. When loading a font, the file selection will return to let you select another file to load.
v0.0.6
Per request of Toby: changing directories in the file selection menu is now possible. Warning: tested only with FAT16 so far - FAT32 could/should work. Please report bugs.
v0.0.7
Also per request of Toby: add VGA support. Sorry for the black borders, perhaps someone can calculate a video timing so that the 768x512 mode fills the screen?
v0.0.8
Fixed (hopefully) the file selection code. The sorting of directories was working by accident only because of an uninitialized variable. Please report bugs.
v0.1.0
Add autostart. If a *.NAS file contains Exxxx after the "." ending the hex input, with xxxx being the entry point, the emulation enters this string into the SIO rx buffer so that NASSYS1.ROM executes it as if it were typed on the serial port.
v0.1.1
Not released
v0.1.2
Catchup with fixes and changes in the ./lib path incurred by other qz80 projects.
v0.1.3
Add detection of Ctrl+Alt+Delete to the keyboard driver to reset the Propeller.

CVS Software repository
The easiest way to follow the development and update your local copy of the sources is to use CVS. For Windows there is e.g. WinCVS or Tortoise CVS, which are free under the GPL. The experienced Linux user will most probably prefer the command line CVS for its simplicity of use. If OTOH you are of the point+click Linux user branch, you may want to open up your favorite package manager and search for "CVS", which will certainly bring up a bunch of GUI clients for CVS to choose from.

You need to know the CVS server. It is ": pserver:anoncvs@pmbits.ath.cx:/anoncvs" - without the double quotes and without the blank after the first colon
Your login name is "anoncvs". Your login password is empty (i.e. none).
If you are interested to contribute and thus want write access to the repository, don't hesitate to ask.
The projects currently are:
  • lib various software library objects that are shared among projects
  • qz80 the CP/M and MP/M emulation
  • trs80 a Tandy TRS-80 emulation
  • nascom this project
  • m100 Tandy M100 portable computer emulation
There are also some now obsolete projects which might go away anytime soon.

After once logging in to the server, you can fetch the various projects and always upgrade to the latest source. CVS deals with local modifications to files by trying to patch in changes into your local copy of a file, so setting some of your target specific parameters should most of the times work with updating.

There's also a CVSWeb-Server running at http://pmbits.ath.cx/cgi-bin/cvsweb/anoncvs/. You can browse the projects there and look for changes etc.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects

Post Edited (pullmoll) : 6/5/2010 5:01:44 PM GMT
1400 x 1050 - 289K
1400 x 1050 - 165K
1400 x 1050 - 115K
1400 x 1050 - 144K
«13

Comments

  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-04-27 23:05
    This is going to be fun! www.nascomhomepage.com/ I see pacman and space invaders. Does this work on vga or only on TV?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • pullmollpullmoll Posts: 817
    edited 2010-04-27 23:25
    Dr_Acula said...
    This is going to be fun! www.nascomhomepage.com/ I see pacman and space invaders. Does this work on vga or only on TV?

    TV only, because I have no good sample code for a monochrome VGA object. The resolution is 384x256 pixels, so it is even PAL TV only.. NTSC would be out of specs: too many scanlines. Edit: despite violating the specs, it seems that NTSC could be working if you tweak your monitor. I can get it to sync on my PAL monitor.
    Pacman and Galaxian worked, and now I compiled a "Hello world!" with BLSPAS, the predecessor of Turbo Pascal.

    I'm working on a quick *.NAS loader and file selection, just like TRS80 CMDs.
    Transferring files to the Nascom with 1200 baud is just too slow [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects

    Post Edited (pullmoll) : 4/28/2010 11:08:27 AM GMT
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-04-28 00:32
    PAL is the standard for Australia too. I have a small LCD display (used as a second screen for portable DVD players etc). I have a feeling it can handle PAL or NTSC. Is your TV circuit the standard 3 resistor one? I need to join in the fun.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • pullmollpullmoll Posts: 817
    edited 2010-04-28 00:33
    Dr_Acula said...
    PAL is the standard for Australia too. I have a small LCD display (used as a second screen for portable DVD players etc). I have a feeling it can handle PAL or NTSC. Is your TV circuit the standard 3 resistor one? I need to join in the fun.

    No, it's just 1 resistor - the code is again based on Cluso99's 1pinTV. You can use the standard 3 resistor circuit, it's just that only one output is used.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-04-28 02:48
    Ah, I have just emailed my mate in NZ. He has been rebuilding Nascom's. You may find him here soon!
    I helped connect a prop to a Motorola D2 for him to replace the keyboard and display.

    Mike will have all the answers I am sure. IIRC he has the assembler roms, etc.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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

    Post Edited (Cluso99) : 4/28/2010 2:53:58 AM GMT
  • pullmollpullmoll Posts: 817
    edited 2010-04-28 08:29
    Cluso99 said...
    Mike will have all the answers I am sure. IIRC he has the assembler roms, etc.

    That's great. After figuring out the somewhat strange keyboard interface, I hope I can also add an emulation of the floppy disk controller. It would make the emulation more complete and useful. The PIO is also left TODO.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-04-28 08:37
    Whilst I am overjoyed that you have acheived so much, so quickly, now you have done the Nascom, I'm going to have to find something else to dream about now !

    Probably just as well as my new job requires me to do some thinking (always tricky) and the dreaming time is very restricted now. I can't wait to have a few days off to play with this.

    Thankyou



    Alan

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • BaggersBaggers Posts: 3,019
    edited 2010-04-28 08:48
    Great progress pullmoll [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • pullmollpullmoll Posts: 817
    edited 2010-04-28 10:43
    Baggers said...
    Great progress pullmoll [noparse]:)[/noparse]

    Thanks! It would be great if you could whip up some colour enabled TV driver based on (or similar to) the 1 pin TV code, i.e. easy enough to understand for my kind of ignorance smile.gif
    Then I could think of a number of Z80 computers to add to the show... I'd be keen to emulate the EG2000 Colour Genie, because I used to write games for this one in the early 80s.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects

    Post Edited (pullmoll) : 4/28/2010 11:10:00 AM GMT
  • BaggersBaggers Posts: 3,019
    edited 2010-04-28 13:07
    What board are you using? and is it compatible with my drac blade? ( DrA? )

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-04-28 13:24
    I'm pretty sure he is using the dracblade but he has the 1 pin TV driver instead of the vga driver. Not 100% sure which pin. But otherwise, just the standard board.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-04-28 19:27
    The KBD was a Licon magnetic saturation sort. The original had about 12 keys less than the later ones. With a butchered keyboard about 4 of us added on thes missing keys.The matrix was a bunch of ferite bead transformers, when the key was pressed a magnet surounded the core and the pulse wouldn't get through. Latches were used to sence this and then the mapping was done. Nas-sys used more modern characters for the reading, earlier monitors just used anything and hence were often incompatible. I used to have selectable ROMs.

    1200 Baud, slow!?! The N1 originally used a sub-devide of the video chain and ended up at about 250 Baud. An add on board got me up to the dizzy heights of 2400 Baud, but 1200 and 300 were always more reliable (and let you make a coffee whilst it loaded)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • pullmollpullmoll Posts: 817
    edited 2010-04-28 19:56
    Baggers said...
    What board are you using? and is it compatible with my drac blade? ( DrA? )
    Yes, I'm using a DracBlade. I added the resistors for TV. It isn't clean, because also the VGA resistors are on board, thus altering the mixing levels, but so far it didn't hurt me. I guess that ideally you would have to switch between the outputs and disable either set of resistors, or at least the ones that build DACs.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects
  • pullmollpullmoll Posts: 817
    edited 2010-04-28 20:01
    Toby Seckshund said...
    The KBD was a Licon magnetic saturation sort. The original had about 12 keys less than the later ones. With a butchered keyboard about 4 of us added on thes missing keys.The matrix was a bunch of ferite bead transformers, when the key was pressed a magnet surounded the core and the pulse wouldn't get through. Latches were used to sence this and then the mapping was done. Nas-sys used more modern characters for the reading, earlier monitors just used anything and hence were often incompatible. I used to have selectable ROMs.

    1200 Baud, slow!?! The N1 originally used a sub-devide of the video chain and ended up at about 250 Baud. An add on board got me up to the dizzy heights of 2400 Baud, but 1200 and 300 were always more reliable (and let you make a coffee whilst it loaded)

    The keyboard tidbits are interesting. Fortunately one doesn't have to emulate things at _that_ level. It took some time until I understood how the keyboard columns are addressed by the 4bit counter and 1-of-10-demultiplexer, but now I have it right.

    I have experienced the world of 1200/75 "Bildschirmtext", so I know about the heights of 2400 and even faster smile.gif Today 1200 seems to crawl as if you could speak out the bytes while they are streaming.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects
  • pullmollpullmoll Posts: 817
    edited 2010-04-28 20:05
    Dr_Acula said...
    ... instead of the vga driver.

    The main problem here is that I have no code to start off with for VGA. I think I would need different timing, but I haven't tried. It's not entirely obvious for me how to drive the hsync and vsync pins with the waitvid opcodes. A monochrome display should otherwise be easy enough to do on a VGA, too.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects
  • BaggersBaggers Posts: 3,019
    edited 2010-04-28 21:37
    DrAcula, can you PM or email me a list of IO's that are used on the prop / dracblade board, I noticed on the board, there are 5 spare IO's in a section in the corner, close to the power socket, are they connected directly to the prop? or are they through another IC?

    Cheers,
    Jim.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-04-28 21:53
    I get Fat mount failed : -1. I'll play with it a bit more, tomorrow.

    I don't think that there was ever a standard for sound on the Nascoms. Some large addon boards gave colour graphics and AY-3910 (or something like that) programmable sound chips. I just messed with the spare bits on the Port0, for beeps.

    The Nascom2 tried for the US market by only clocking out 12 of the 16 character rows, this alowed for NTSC scan rates but screwed up the block graphics.

    The countdown of spare cogs, does this count the initial one used for spin ??

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • pullmollpullmoll Posts: 817
    edited 2010-04-28 22:52
    Toby Seckshund said...
    I get Fat mount failed : -1. I'll play with it a bit more, tomorrow.
    I will try to replace DracBlade_spi_warp with DracBlade_spi (some PUBs are missing) so you can try that. Oh, won't work out of the box because of completely different inner structure.
    The current DracBlade_spi_warp code should actually detect all types of SD cards. I don't know why it fails for you.
    Toby Seckshund said...
    I don't think that there was ever a standard for sound on the Nascoms. Some large addon boards gave colour graphics and AY-3910 (or something like that) programmable sound chips. I just messed with the spare bits on the Port0, for beeps.
    Ah, the AY-3-8910, yes, a very well known chip. I could / should add an object for that one. 3 tone generators, 1 noise generator and 16 amplitude envelopes. I've written emulations for this one in C, so it should be easy enough to do in PASM.
    Toby Seckshund said...
    The Nascom2 tried for the US market by only clocking out 12 of the 16 character rows, this alowed for NTSC scan rates but screwed up the block graphics.
    With 12 lines per character the block graphics is wrong, yes. 15 actually makes it better, because 15 is divisble by 3. I guess 240 visible scanlines is still at the very limit of what NTSC can display, but easier than 256.
    Toby Seckshund said...
    The countdown of spare cogs, does this count the initial one used for spin ??
    Yes, the initial one is used until the qz80 cog eventually starts. It uses cog 0, since there is no Spin code running once everything is set up.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects

    Post Edited (pullmoll) : 4/28/2010 11:06:39 PM GMT
  • pullmollpullmoll Posts: 817
    edited 2010-04-28 23:01
    Baggers said...
    DrAcula, can you PM or email me a list of IO's that are used on the prop / dracblade board, I noticed on the board, there are 5 spare IO's in a section in the corner, close to the power socket, are they connected directly to the prop? or are they through another IC?

    Jim: You're most probably seeing the "high latch" ouputs. 3 bits of that latch are used for A16..A18, one bit is connected to an LED on my board - it may be unused on your board - and 4 pins are left for other purposes. AFAIK there are no free prop ports left to use for TV out, which I guess is what you are looking for?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-04-28 23:07
    Re "I guess that ideally you would have to switch between the outputs and disable either set of resistors" = very good idea. I've changed that on the latest board so there are jumpers and you can add these as needed for vga or TV. Also a space on the board for RF modules. I haven't sent these boards off yet to be made as I think more things are coming. eg the comment about an AY sound synth in software. So for hardware would you use a R and C and an audio amp LM386 or something? I might be able to find room for that underneath the RF module.

    I see you disable the original spin cog - does this free up cog0 ? If so, that is very clever, and using that cog for audio would be brilliant.

    Re " I noticed on the board, there are 5 spare IO's in a section in the corner", yes those are the spare pins on the High latch. Three are used for A16-A18, one for a diagnostic led and the others are spare. I used to know how they worked on the old code, but I'm not sure with the new code. Can you access them with an OUT in some way? (if so, you would need to mask the ram bits).

    There are no free pins on the propeller if you are using VGA. However, with TV there are quite a few spare propeller pins.

    Re VGA and pixels, I'm still not entirely clear what the problem is, nor how to solve it. But see Bean's Propbasic thread http://forums.parallax.com/showthread.php?p=867134 if you scroll down to a post I made on the 28th Jan and then some subsequent posts, there is a photo of a demo running on a VGA monitor on a Dracblade with an awful lot of coloured pixels. A comment in a post a few further down from Bean about loading up a palatte for each individual line. Obviously, this uses quite a bit of hub ram, and maybe that involves reusing cog space or something. But the questions have not been about hub ram, they have been questions about timing and so if Bean is doing this then it must be possible. I posted a 'step by step' for propbasic on the 23rd Jan. There is a photo on 2nd March I took with coloured text on coloured background and every letter is different.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller

    Post Edited (Dr_Acula) : 4/28/2010 11:53:58 PM GMT
  • pullmollpullmoll Posts: 817
    edited 2010-04-28 23:48
    Dr_Acula said...
    Re "I guess that ideally you would have to switch between the outputs and disable either set of resistors" = very good idea. I've changed that on the latest board so there are jumpers and you can add these as needed for vga or TV. Also a space on the board for RF modules. I haven't sent these boards off yet to be made as I think more things are coming. eg the comment about an AY sound synth in software. So for hardware would you use a R and C and an audio amp LM386 or something? I might be able to find room for that underneath the RF module.

    I actually connected my audio output without anything to the audio input of my monitor. There's certainly an R/C circuit in there, while I don't know the specs. I guess an R/C/R combination to limit the output signal to 1V and attenuate frequencies above 20kHz or something like that would be good to have. Not sure if an on board amplifier makes sense, as most people won't connect just a speaker, but either head phones or some kind of amplifier.
    Dr_Acula said...
    I see you disable the original spin cog - does this free up cog0 ? If so, that is very clever, and using that cog for audio would be brilliant.

    Yes, I use coginit(0, ...) as the last step which kills the Spin interpreter. Currently there's 1 cog or even 2 cogs left with all emulated machines IIRC.
    The TRS80 doesn't need any additional audio. There may have been external audio solutions, but none that were very widely used. The 3 level cassette signal is handled in the io cog.
    The M100 has just the cassette port, but I don't think it was used for audio.
    The Nascom seemingly has no standard for audio output. I may try to write an AY-3-8910 emulation, while none of the games or programs on nascomhomepage.com seems to make use of it. It would be required for the Colour Genie, though, so it wouldn't be a waste of time if I tried.
    Dr_Acula said...
    I used to know how they worked on the old code, but I'm not sure with the new code. Can you access them with an OUT in some way? (if so, you would need to mask the ram bits).

    The LED is used in qz80 CP/M to indicate SD access. It is always set on with the high latch value in io.spin, and the next high latch write in qz80.spin turns it off again.
    No, the other bits are currently not useable. It would require me to have the bits accessible in both cogs and it would certainly slow down the RAM access even more, while I just managed to make it faster by avoiding to write the middle and high latch when not necessary. If you absolutely need it, I could try to squeeze the 3-4 instructions required to combine the high latch with the other port bits. This is all DracBlade specific, though, as is the high latch writing in io.spin. If I ever manage to get the RamBlade working, I would have to either simulate the high latch or clutter the code with #ifdefs. Perhaps the high latch writing could be handled in DracBlade_spi_warp - and DracBlade_spi - internally, so I would just put the full 512KB address in the RAM address long for XMM read/write.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects

    Post Edited (pullmoll) : 4/29/2010 12:26:43 AM GMT
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-04-29 00:26
    If using the other latch pins will slow things down then maybe don't do this.

    Of course, there are spare output pins on the 20x4LCD latch that could be used for anything really, not just a display.

    I post edited some comments on my last post re VGA and graphics/text.

    Re audio, the prop can probably create a standard 1V audio signal directly, so yes, simpler just to leave as-is. Or copy the circuit off the demo board?

    Why is the baud rate so slow? Is it possible to use the software uart that CP/M uses?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • pullmollpullmoll Posts: 817
    edited 2010-04-29 00:50
    Dr_Acula said...
    Why is the baud rate so slow? Is it possible to use the software uart that CP/M uses?

    This is what I use. The real machine had the limit of 1200 baud with the internal hardware (clock frequency) and it seems I overrun the text mode input with data as soon as I go higher than 2400 baud. This is probably because the text is echoed to the local video and this takes some time. 2400 only works because there is no software rate programming, but just a switch on the real hardware and the software isn't aware of the rate anyway.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects

    Post Edited (pullmoll) : 4/29/2010 1:03:59 AM GMT
  • pullmollpullmoll Posts: 817
    edited 2010-04-29 00:59
    Dr_Acula said...
    Re VGA and pixels, I'm still not entirely clear what the problem is, nor how to solve it. But see Bean's Propbasic thread http://forums.parallax.com/showthread.php?p=867134 if you scroll down to a post I made on the 28th Jan and then some subsequent posts, there is a photo of a demo running on a VGA monitor on a Dracblade with an awful lot of coloured pixels. A comment in a post a few further down from Bean about loading up a palatte for each individual line. Obviously, this uses quite a bit of hub ram, and maybe that involves reusing cog space or something. But the questions have not been about hub ram, they have been questions about timing and so if Bean is doing this then it must be possible. I posted a 'step by step' for propbasic on the 23rd Jan. There is a photo on 2nd March I took with coloured text on coloured background and every letter is different.

    If I counted right, the display is 40 characters wide. Baggers and I were discussing an 80 columns display which is much more demanding cycle wise. You can't do too much on a TV 80 columns display, and on VGA the timing is even tighter, because the scanline rate as well as the refresh rate are higher than on a TV. You don't want to run CP/M or MP/M using a 40 column display, or do you?

    I don't see a post on 2nd of March in that thread. Do you have the exact link?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-04-29 01:51
    The US date system got me! It was the 3rd Feb.

    Ok, text is 40 cols, but the graphics was a lot more pixels.

    Re 80 col text vs less columns graphics, we almost need a "text" and a "graphics" mode. Would that be two different vga drivers? Could you load one, then load another one? That starts to get like the project Cluso is working on with portable cog objects that are stored on an sd card and can be loaded and reloaded. Your code might be the closest to doing that as you have virtually eliminated spin, and it was the spin glue that was one of the problems.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • pullmollpullmoll Posts: 817
    edited 2010-04-29 03:28
    Dr_Acula said...
    The US date system got me! It was the 3rd Feb.

    Ok, text is 40 cols, but the graphics was a lot more pixels.

    Re 80 col text vs less columns graphics, we almost need a "text" and a "graphics" mode. Would that be two different vga drivers? Could you load one, then load another one? That starts to get like the project Cluso is working on with portable cog objects that are stored on an sd card and can be loaded and reloaded. Your code might be the closest to doing that as you have virtually eliminated spin, and it was the spin glue that was one of the problems.

    I looked at the VGA_demo4 code and it is 320x240 pixels. Not sure about the colour resolution. The text colors were the same for pairs of 2 characters, and it might be this is in how the VGAvideo.spin works. It looks like there are 10 bytes palette per scanline. The two constants palette_ofs and font_ofs are 2400 bytes apart, and 2400/240 = 10. It could also mean 80 bytes per 8 scanlines, so you would have 4 colours per 4 pixels but the same for each set of 8 consecutive scanlines. The video mode seems to use 19200 bytes of hub RAM, 80 bytes per line in 240 lines. Each byte contains the colours of 4 pixels - the selected video mode is the 4 colour mode.

    While this mode may be useful for games, its memory consumption is tremendous and not compatible with anything using the Z80. Two such memory hungry objects will never work together.

    We _might_ try to get this sample code working with reading the data from XMM, but I think it will be too slow, even if we waste RAM by using a scanline pitch of 256 bytes for faster addressing of the bytes. The code does rdlongs to fetch the pixel data from hub RAM. With XMM this would be 4 byte accesses with incrementing the LSB latch and probably too many instructions, if the XMM RAM can be accessed that fast at all.

    No, I tried to change the core loop of VGAVideo.spin to read 4 bytes from hub RAM and combine them into a long and this is already too slow and the mode is no longer synchronizing the VGA. This is with fast hub RAM, so it will fail with XMM in any case.

    The only chance I see to get XMM used for video is with a text mode where e.g. 80 bytes of XMM have to be fetched once every 8 (or more) scanlines "only". With 2 alternating character rows in cog RAM you could probably get away with the text buffer in XMM at the cost of quite a bit of memory bandwidth for the Z80 lost to the video.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects

    Post Edited (pullmoll) : 4/29/2010 4:01:13 AM GMT
  • pullmollpullmoll Posts: 817
    edited 2010-04-29 06:34
    I have some good news! After experimenting with the VGA driver from PropBasic, I got a stable video mode with 480x240 pixels. That would suffice for a 60x30 with 8x8 chars video display. I think I can go to 640x240 as well, just increasing the PLL frequency to twice the original, then we could have 80x30 with 4 colours per 2 characters, i.e. full character attribute support.

    I also modified the video code to take its data from a two rows character and palette buffer. Now I will try to set up a second cog to render the character and attribute data to this buffer alternatingly and in sync with the video cog. I know this will be tight, but perhaps I can manage it with some clever adjustment of the font arrangement in memory.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-04-29 06:47
    Ah, this sounds promising.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • pullmollpullmoll Posts: 817
    edited 2010-04-29 07:10
    ...but it's not so easy as it seems. By doubling the PLL frequency to 250 Mhz the cog doesn't have enough time to read the palette and pixel longs and push them into the waitvids. The effect is a very blurry picture which hardly syncs on the monitor. By slowly decreasing the PLL frequency I found that a factor of 42 almost works (42 * 5 = 210 MHz), but the LCD monitor complains that the frequencies are not supported. It then doesn't let me enter the menu to show the hfreq and vfreq values. DUH! Going even lower seems impossible, going just a little higher like 43 and 44 doesn't help either, and from 45 on (= 225MHz) the cog isn't fast enough anymore.

    I then tried to add some more pixels to the h + v synchronizing pulses, because they are much shorter now. This didn't really help. The best result I could get that way was a rather stable picture, unfortunately with column #79 missing and instead appearing on the left side, followed by the vertical black bar that should be the invisible hblank.

    So it really looks like it's difficult if not impossible to get things done at this high frequencies - and the monitor doesn't take (much) lower frequencies but loses the synchronization.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects
  • pullmollpullmoll Posts: 817
    edited 2010-04-29 07:23
    Gotcha! I finally found a combination of values that syncs cleanly on my monitor! It uses 215 MHz (PLL x 43) and 10 PLL clocks per pixel, so the pixel clock is 21.5MHz. The hsync is 3x16 and the horizontal porch 2x16 wide. Would you try if it works for you too? Currently it displays a fixed pattern of some colors, not text yet.
    @Baggers: In case you are following this thread: This is the mode I meant to use. With 4 colours per 16 pixels we can have 2 x 8 width characters with separate fg and bg color. Now there's just the renderer that fills the 2 rows buffer left to do.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects

    Post Edited (pullmoll) : 4/29/2010 7:34:43 AM GMT
Sign In or Register to comment.