 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PICO-56 nice Project
Page 1 of 2   |
|||||
| Author | Message | ||||
atmega8 Guru  Joined: 19/11/2013 Location: GermanyPosts: 722 |
Any Suggestions about this nice Project. Also usable for MMBASIC? https://www.youtube.com/watch?v=Nj_KkYn7YaA https://github.com/visrealm/pico-56 |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
MMBasic doesn't support that VGA. The PS2 keyboard is on the wrong pins. So no, a PicoMite VGA won't run on that PCB. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| cosmic frog Senior Member  Joined: 09/02/2012 Location: United KingdomPosts: 284 |
I've been looking at this and I'm in the middle of building one on a piece of strip board. The BASIC looks a bit basic with line numbers but the games and demos look really nice. Dave. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
That's to be expected, I think. To get that screen resolution and number of colours any frame buffer is going to have to be a lot bigger. That will leave less space in RAM for any portions of BASIC that aren't running from flash and for any variables and user program. More space will be lost for the sound chip emulation. This isn't a great problem if you are writing your code in C, assembler or it's compiled on something else, but fitting a decent BASIC interpreter in as well is probably not possible. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
back when i was a lad, folks fitted a decent basic interpreter into 8k of ROM. 16k was a luxury, and 32k - well with that you could fit in basic interpreter, assembler, networking, and a complete bathroom ensuite. but seriously, mmbasic does contain an enormous quantity of vanity code that goes way beyond the minimum requirements of a games machine - it could be stripped back to the bare minimum and/or possibly rewritten from scratch to achieve similar performance and compactness to interpreters of olde. the down side, you would loose much of the versatility and maintainability. cheers, rob :-) ... and i'm very impressed they were able to generate an 800 x 600 VGA output, Peter had led me to believe that this was impossible. makes me wonder if the picomite VGA could be persuaded to achieve 800 x 450 (ie, 18:9 widescreen) if Troy Schrapel's video code could be shoehorned into it. Edited 2024-01-18 15:30 by robert.rozee Footnote added 2024-01-18 17:41 by robert.rozee looks like 720 x 400 is a valid 16:9 VGA mode, with a dot-clock that is even lower than that of 640 x 480. |
||||
| okwatts Regular Member  Joined: 27/09/2022 Location: CanadaPosts: 59 |
I have been following this project and have built a unit. The main purpose so far has been to emulate his HBC-56 6502 computer. The basic is a version of Microsoft basic widely used in the 6502 community. The issues with the board as built is that the pin usage is different from that of Picomite VGA as well as the VGA being 444 not 121. That's not to say that it couldn't be adapted but that is beyond me and we already have a better version of basic although with limited colours compared to that. Don't get me wrong I am a fan because I am a 6502 enthusiast which is why I have adopted the PICO-56 but I wouldn't give up the value and experience that I get from MMBasic on the Picomite. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
The thing is, Rob, MMBasic isn't (and never was) designed for writing games in. There are more efficient versions of the language that were designed for this purpose (remember GFA basic?). However, MMBasic has been improving rapidly in that direction. :) As far as the display goes, a 800x450 frame buffer would take up: in mono: (800*450)/8 = 45kB in RGB444: (12*800*450)/8 = 540kB The Picomite VGA uses 38.4kB in both modes (because the number of pixels is reduced to allow colour). Note, Tile mode adds a bit of extra RAM to Mode 1 to carry the tile info. Note: no Pico can display using a frame buffer that exceeds its RAM. You'll still need some sort of workspace even on a minimal system, so the upper limit is probably a little over 200kB if you have no BASIC and no user program and no editor and no variables taking up RAM space. You can't use flash for the frame buffer - it's too slow. You can make a screen *appear* to be high res colour by using some fancy tricks, but it's not pixel addressable. Consequently some games and demos can be *very* impressive. It is impossible to create a RGB444 800x450 display on a PicoMite as it needs over twice the available RAM on the chip! Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
i suspect Geoff may take exception to that claim! the original maximite (mono and later colour) were both squarely orientated towards games. as i recall they didn't even make use of the pic32mx695's onboard peripherals (apart from spi for VGA output), instead comm ports, i2c, etc were all bit-banged in software. it was only with the micromite (mx150/mx170 and later) that onboard hardware peripherals were made use of. regarding different video modes: 640 x 480 / 8 = 38400 bytes 720 x 400 / 8 = 36000 bytes so in 2-colour modes (1 bit per pixel) 720 x 400 actually uses a frame buffer that is slightly smaller that 640 x 480. hence, also a slightly lower dot clock is required (albeit by only a small margin). tiles could be a little tricky, as if displaying 80-column text one would require tiles that are 9 pixels wide. then there is the vertical division: 400 / 24 = 16.7 pixels high --> 16 * 24 = 384 + 16 blank scanlines left over 400 / 25 = 16 exactly 400 / 30 = 13.3 pixels high --> 13 x 30 = 390 + 10 blank scanlines left over 400 / 32 = 12.5 pixels high --> 12 x 32 = 384 + 16 blank scanlines left over so an 80 x 25 character screen would be a good choice for working with text, followed by the next best being 80 x 30 characters with 5 blank scanlines at top and bottom of the VGA display. cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9115 |
720x400 uses a dot clock of 35.5MHz vs 25.175 for 640x480 ref and most modern monitors don't support the old vesa timings Edited 2024-01-18 19:39 by matherp |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
good point Peter, i was assuming the same frame rate throughout  but the look at the dot clock for the various 800 x 600 modes: (from: http://tinyvga.com/vga-timing) the lowest is 36MHz. so if Troy Schrapel's video code is outputting at even the lowest of these, then 720 x 400 at 85Hz (35.5MHz dot clock) should also be possible: what magic is he doing that allows for a 36MHz dot clock? cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
an interesting quote from stack exchange: (from: https://retrocomputing.stackexchange.com/questions/14806/why-do-pcs-boot-in-720x400-resolution) this suggests that 720 x 400 is an extremely common mode that is still in use today. cheers, rob :-) Edited 2024-01-18 20:06 by robert.rozee |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9115 |
The discussion is moot as I won't be making this sort of large scale change. The source is available if you want to try Edited 2024-01-18 20:20 by matherp |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
it also looks like 720 x 400 at 70Hz with a dot clock of 'only' 28.322MHz is a thing. see: https://techdocs.altium.com/display/FPGA/32-bit+VGA+Controllers+-+Timing+Information last time i checked, it had been well established that the world actually revolvs around the sun: https://www.astronomy.com/science/when-did-we-realize-that-the-earth-orbits-the-sun/ cheers, rob :-) Edited 2024-01-18 20:38 by robert.rozee |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
I see no mention of designing a computer for games on this page, Rob. A lot about it being similar to a 8-bit home computer though. In fact, I don't think the word "games" occurs on the page at all. :) Try modifying the VGA, Rob. Let us know how you get on though. If you can get it to work you *might* change Peter's mind. Seriously, why mess with something that's working and already supported? If you want flashy displays and demos use PicoVGA instead. That was designed for it. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4234 |
It is amazing what the pico all can do. I see with amazement that there are people running higher resolutions VGA, and use real audio DAC's. But I realize that all comes at a cost. I think the picomiteVGA is a well balanced package that is so flexible that it can be used for zillions of applications. You can change the balance ... in example by increasing the VGA resolution, or the color depth, but it comes at a cost (if Peter would ever consider to do it). Look at the nice retro computer platforms that are promoted for the pico (like this one).. you have a basic with 32kbyte work space and a ancient basic interpreter without edit mode. PETSCII ROBOTS would never have worked on that unit, nice graphics, but no game. The only improvement I could think of that could benefit the current platform (but it would be largely backward incompatible unless very wel thought through) is 16 color VGA palette mode from 64 colors. This would come at a cost of 2 IO pins (RGB2:2:2), but would still use the same memory footprint. This is the most simple way to add the color GREY to VGA. But this is also too late in the game for the PicoMite VGA platform. Leaves a CMM2 to do this kind of fancy stuff. Volhout Edited 2024-01-18 23:55 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
Wouldn't RGB222 take 6 x 320 x 240 = 57.6kB for the frame buffer? Unless you reduce the resolution again. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 509 |
It would still be only 16 colours at any one time, but from a pallet of 64 colours, so the frame buffer would stay the same size, but you could select what colour each of the pixels would be from a larger pallet, probably on a whole screen basis, rather than on a pixel by pixel basis, ie the buffer pixel value of 4, could be defined to be full on red, or 110000 as a bit pattern, but for the whole screen, and only 16 colours in total. Personally I'm perfectly happy with the colour mix that we have, as the best compromise until the rp2040 is redesigned with significantly more ram. Regards Kevin. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
The problem with that is that the actual colour generation is done by the resistor network, not by the firmware. That only outputs a 4-bit value from 0 to F on the VGA pins. You can change the resistor network to get any colours you like (including greyscale), but you end up with a non-standard system. You *could* output a 2-bit binary value on two extra pins to select which of four banks of 16 colours are displayed but it could get horribly complex. :) It would only work with your hardware too, which is a bit of a disadvantage. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4234 |
The idea for 16 color palette from 64 colors with the current HW architecture is that we would use 8 (versus 6) pins for VGA. HSYNC VSYNC Blue1 Blue0 (new) Green1 Green0 Red1 Red0 (new) The trick would be that there would be a lookup table that maps the 16 colors to 16 of the 64 possibilities for the whole screen. If we can in any way implement the lookup table in PIO0 then there is not a single line of MMBasic needs to change....but.... 1/ The PIO code must be analyzed to see if this can be done while maintaining the timing accuracy VGA requires. And there are only 32 program steps. Maybe the best that can be achieved is a fixed palette. Or 8 fixed colors (CMM1 colors) and 8 selectable from the remaining 56. Or sacrifice the second PIO. With a fixed palette there will be endless discussions what colors should be in there. A lookup table in ARM code is more flexible, but then the FIFO's have to handle groups of 6 bits (i.e. 5 x 6bits in 32 bit fifo) which is far more CPU intense. Or use 4 x 8 bit and throw away 2 bits of each 8. Effectively doubling the bandwidth required for sending video. The PIO can handle that easily, but the ARM may not. 2/ This ties in into everything if you want to make it usable in MMBasic. That is where the major changes come. And that is why this is out of scope. Load 24bit BMP picture ... how to determine the best pallette ? What do you do when a palette changes ? Currently the PIO is not dynamically re-programmed, but only at startup. Lots and lots of development and architecting. And I am fully with Peter that this is not the moment, and not for this platform. Maybe in the future there is a bigger chip, or there is (on the same chip) a PicoMiteVGA2 that has a different hardware platform. There is also an option to do this external. Write the palette to an external (FAST) 8 bit wide RAM chip (64x8 is enough). Note you have to pass HSYNC and VSYNC through the same chip to make sure the timing sticks. Volhout Edited 2024-01-19 03:01 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
Or... change the existing resistors for red and blue to be the top end of potential dividers. The tap goes, via another resistor to a new pin. If new pin is off (not high) the original pin drives at the original level. If the new pin is low it reduces the drive from the original pin to a new half level. Just set the new pins to OFF or 0 to set the group of 16 colours required. It may need some fiddling with all the resistors to avoid overloading red and blue outputs while keeping the white balance. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Page 1 of 2 |
|||||
 Print this page |
