 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 : Seeking Games Programmers
  Page 3 of 9   |
|||||
| Author | Message | ||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 3678 |
That suggests it would be handy to have a pre-soldered CPU, especially if it has 176 contacts. You don't need to run Linux and as I understand it you also don't have to go the "commercial in confidence" route - otherwise the existing non-Linux OSes etc would not be available let alone free. However, it's more work and if you don't use an OS you have to roll your own graphics and much more - things like USB host/device/OTG, LAN (TCP/IP), WiFi, ... are quite a bit of effort. The cost of the RPi is of course very attractive so a stripped down OS (maybe Linux, maybe not) might be the way. If the MZ with 32MB internal RAM is very cheap then clearly it would provide a roughly instant-on big brother to the CMM, even though it will not approach the features of the RPi (with perhaps a stripped down Linux). John |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
|
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8605 |
The existing Micromite eXtreme can support 640x480 VGA RGB111 and 640x400 RGB111. This can be converted to HDMI with a very cheap adapter The MZ with 32MB internal RAM can support a a maximum of WVGA (800x480) and is designed to drive LCD panels. NB WVGA is not a supported VESA standard and I can't find any cheap VGA adapters that support it and many VGA monitors may not support it. It is possible (probable?) that the MZ with 32MB internal RAM could drive VGA @ 720x400 70Hz in 24-bit colour using external R2R DACS and this is a VESA standard supported by the adapter referenced above. There is plenty going on using the Raspberry Pi in bare metal mode so it is not impossible to port to a Pi without Linux. The framebuffer looks easy enough and there is some, but limited work on USB drivers |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
peter: it can't by any chance be reduced down to 512 pixels wide, can it? the reason i ask is that this may display more sharply on a 1024x786 (15") monitor than 640 horizontal pixels. however, it may requiring having a little less than 80 columns of text. 800 horizontal pixels wide, i suspect, may display poorly on a 15" monitor, though i do recall there being some 1600 pixel wide monitors at one time that would like it. i guess it all depends upon what monitor is most commonly available 2nd hand at low cost. cheers, rob :-) |
||||
| hitsware Guru Joined: 23/11/2012 Location: United StatesPosts: 535 |
+1 for the Arduino capability (Since no one is considering sound) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8605 |
MM+ and CMM both do sound and it is a given for CMM2 |
||||
| hitsware Guru Joined: 23/11/2012 Location: United StatesPosts: 535 |
I'd forgotten about the MOD format. (Never got it to work and is way out of vogue) The TONE commands have limited use (lacking envelopes) I'm going to revisit the MOD ......... PLAYMOD This command will play synthesised music in the background while the program is running. The music must be in the MOD format and the file containing the music must be located on the internal flash drive (drive A:). The audio is high quality and MMBasic will generate full stereo on the Colour Maximite. The MOD format is a music file format originating from the MOD file format on Amiga systems in the late 1980s. It is not a recording of the music (like a MP3 file) - instead it contains instructions for synthesising the music. On the original Amiga this task was performed by dedicated hardware. MMBasic will read this file and continuously play the music in the background while the program that launched the music will continue running in the foreground. Be aware that synthesising music is a CPU intensive activity and uses a lot of memory and this could affect the performance of the program. A description of the MOD format can be found at: http://en.wikipedia.org/wiki/MOD_(file_format) A large selection of files that can be played on the Maximite can be found at: http://modarchive.org (look for files with the .MOD extension). Because the file must be located on drive A: to play it would be wise to select reasonably small files. You can also create your own music using a tracker. For an example see: http://www.modplug.com TONE This command will create two tones for the Colour Maximite that will be outputted separately on the left and right sound channels. On the monochrome Maximite only one tone is generated. The tone is a synthesised sine wave and can be in the range of 1Hz to 20KHz with a resolution of 1Hz and is very accurate as it is locked to the PIC32's crystal oscillator. When the frequency is changed there is no interruption in the output so the output can be made to glide smoothly across a range of frequencies. The playing time can be specified in milliseconds and the tone will play in the background (ie, the program continues running). SOUND The sound command is included only for compatibility with older programs. It generates a single frequency square wave and should be replaced with the tone or PWM command in new programs. |
||||
| Heidelberg Newbie  Joined: 22/01/2018 Location: AustraliaPosts: 13 |
Hi! New member here. I have been tinkering with micromites for some time and lurking here off and on for a while also. Although I have never owned a maximite unit I'm quite interested in this thread and felt compelled to respond. I think a MZ based computer with the aim of being more of a 80's retro computer rather than a embedded controller is a great idea which would definitely appeal to a whole new demographic. In the 8-bit era decent games were always programmed in assembly as interpreted basic was far too slow and to produce a compelling game experience. However a modern 32-bit PIC based computer that had the appropriate features implemented probably could run great games straight from interpreted basic - a very interesting possibility. So what features should be implemented in order to produce a great retro computer platform that would be suitable for great arcade games? Well I suggest to look to the past to see which platforms stood above the others in this regard and what was it was that differentiated them from lesser machines. In my opinion in terms of capabilities it came down to this: 1. Sprites A good sprite implementation with collision detection is mandatory. 2. Graphics modes. Implementation of both bitmap and pattern (or tile) graphics modes. 3. Smooth scrolling. Hardware supported ability to scroll the screen contents vertically or horizontally. 4. Sound. An ability to produce quality sound. #1 Sprites - Machines with hardware sprite implementations without doubt (in general terms) had better games, they were faster and contained more dynamic graphical elements. Computers such as the commodore 64, Atari 8-bit series and MSX series supported hardware sprites and when you compare the bulk of the games for those machines against games on the Sinclair spectrum, Amstrad CPC or acorn electron for example they were superior and more playable. Of course with Z80 or 6502 based machine without hardware sprites you had to move all game graphics elements about manually and also test for collisions manually which used a lot of machine cycles which was a limiting factor to what was then possible to achieve. A fast 32-bit system is not restrained in the same way obviously however a good sprite implementation is still imperative in my opinion. It abstracts the game programmer from much tedious detail allowing them to focus more on the game itself - just be able to define the multicolour sprites and move them about in a simple X and Y fashion is awesome. I had a read the maximite sprite guide and I do agree that it's a bit awkward. I think the implementation should be table based for flexibility and importantly to allow for easy sprite animation. I'm more happy to discuss details around this further if anybody is interested. #2 Graphics Modes - The best 8-bit machines (IMHO) supported both bitmap and pattern based graphics modes. Both the C64 (VIC2 chip) and MSX series (MSX TMS9918, MSX2 V9938, MSX2+ V9958 VDP chips) computers could do pattern (also called tile) based modes in addition to bitmapped graphics modes. Depending on the type of game being programmed and features that would be implemented one mode or the other may prove more appropriate. Pattern or tile modes can be very attractive to game programmers. Very often the same graphic elements appear in a game and are reused over and over. In a tile mode you can define all your tiles and then the screen buffer itself is just a matrix of which tile is to be displayed in each location. Analagous to the text modes on old DOS machines in so far as the screen memory just is a matrix of the character codes and the video card builds and draws each scan line based on this. Look at the platform game 'The treasure of Usas' on the MSX2 for example. Each new screen just defines different tiles to appear in different positions - rather than the programmer having to manually 'draw' everything to be displayed in a bitmap-like fashion. Tile based platform game. #3 Smooth scrolling (ideally both horizontal and vertical) - Machines with hardware supported smooth scrolling (per pixel) had the most appealing and slickest arcade games. The C64 with its VIC2 chip was ahead of its time in this regard. Have a look at these games and see what was possible with hardware sprites and smooth scrolling capability. Many of these games are still very playable and fun even today (in contrast to games on machines that had neither of these capabilities). C64 games - Sprites + scrolling Take a look at the arcade classic '1942'. From a programmers point of view imagine how can just focus on the actual game detail itself if to achieve the scrolling background you only had to copy the next background pixel line into a buffer then execute a 'scroll down' command and the computer just takes care of it. An arcade shooter like this becomes largely a case of implementing all the enemy 'attack patterns' and sprite manipulation. Fast paced games like this could absolutely done on a new maximite and in basic! Obviously at RGB111 games won't be as colourful but the actual gameplay could be just as compelling. 1942 - Smooth scrolling. The MSX1 could not smooth scroll at all but the MSX2 could smooth scroll in the vertical direction. Compare the aesthetic difference between these two fun vertical shooter games. 'Sky Jaguar' on the MSX1 still is a good game but scrolls on an entire per tile basis - certainly not as nice as 'Zanac Ex' which shows off smooth scrolling on a MSX2. Sky Jaguar - MSX 1 Zanac Ex - MSX 2 #4. Sound - Computer sound is not really my area. Its obviously important and I think in terms of capability you really need to be able to play a background tune while also being able to mix in sound effects from the game in progress. MOD based does make sense as there are many trackers, tools and utilities and of course MOD files themselves freely available to work with already. I really think an awesome MZ based retro computer is possible with the right capabilites implemented. Like I said before I'm sure it would greatly appeal to a whole new demographic of users and you'd be amazed with the games and software that the retro computer community would produce. I have some ideas about what could be potentially nice implementations of some the things I have detailed if anybody is interested in the detail. -Heidelberg |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
@Heidelberg Welcome on board - and I must say a very 'valuable' post (really well put across with excellent examples). Hopefully Geoff and Peter will absorb the content and be able to soon give their feedback regarding your points. Any other recommendations you have are more than welcome . . . . For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Why should a retro computer be build with a single chip? Just so you can have less performance and abilities? Why not incorporated a chip that handles video and sound so that the processing power and all of its memory can be used for the program. Have a look at this: https://www.youtube.com/watch?v=4XJUz4-fpb0 That has been done 4 years ago. There is a lot available for that chip so things do not have to be invented. The newer version FT81X is even more powerful. And it is possible to use LCD and als HDMI as output. Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3678 |
Adding a quite costly chip just to do video is probably not the idea here unless there's now a desire to spend more and create a specifically gaming machine. If the MZ can't do sprites etc as needed (well, can it?) then can a faster CPU like the RPi Zero's? I note the FT81X on its own costs about the same! John |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Thanks @Heidelberg I think that we are most of the way to fulfilling your list. Smooth scrolling can be done using the existing BLIT command although it would involve a memory to memory copy so not as fast as hardware. However an efficient 32-bit processor running at 200MHz can come quite close to the old 8-bit hardware speeds. I am not sure how tiling would work and why it is important - is this because tiles could be swapped in/out rapidly? How many tiles would a typical game need? If we had sprites of any size could they be used as tiles? Geoff Geoff Graham - http://geoffg.net |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
I 2nd that. What a marvellous 1st post from that member!!!  Smoke makes things work. When the smoke gets out, it stops! |
||||
Azure Guru Joined: 09/11/2017 Location: AustraliaPosts: 446 |
Tiles (like Heidelberg is describing) on classic arcade games (and the classic computers described) are like a char mapped display, but instead of containing fonts they contain images that can be stitched together (placed side by side and/or vertically) to make game objects, larger pictures or repeated patterns. This is a very convenient game programming alternative to bitmap graphics where the 'game' has to draw the entire image using graphics drawing primitives onto a bitmapped (only) display. Regarding background scrolling on classic arcade games: Some had entire background scrolling in X and Y directions; Some had individual row scrolling (that's how 'frogger' worked; Some had multiple background planes that could be scrolled with one colour defined for transparency. This allowed layered '3D' scrolling effects like in 'Jungle King'. Most of this scrolling was done using tiles (characters) and the scroll was actually an offset from 0 - 7 pixels (the size of a tile). So only the outside tile (character) was partially displayed, The image background was 2 tiles larger in the X and Y direction to allow for this scrolling of the edge character in both + and - directions. |
||||
| Heidelberg Newbie Joined: 22/01/2018 Location: AustraliaPosts: 13 |
Thanks for the warm welcome - I appreciate it  @Geoff I understand that the maximite would be scrolling the screen via a memory copy implemented in firmware rather than actual hardware (in silicon) but providing the maximite responds to a screen scroll command, waits for the next vertical retrace and than then executes the appropriate memory move - the effect is the same and the programmer doesn't have to be concerned with the detail. I believe that the simpler and more elegantly key features are implemented the more attractive the unit will be as a platform for 'old school' arcade games. So I really think that although a scroll can be achieved using the BLIT command, scrolling functionality deserves dedicated basic commands. In bitmap mode for example there could exist two buffers, one for a new horizontal line of pixels and one for a vertical line - both sized appropriately of course. A basic function could exist to update either of these buffers with data, then when a bitmap scroll up, down, left or right command is executed then the maximite firmware does the appropriate memory move and also copies in the required buffer data automatically. Old 8-bit machines generally supported 256 different tiles at one time - because the tile table (effectively the screen buffer when in tile mode) was made up 8-bit integers which selected which tile to display. I think 256 should definitely be the minimum number of tiles you would want to support and that may be enough - it was generally was back then. Supporting 512 tiles may certainly be nicer if resources permit. At a screen resolution of 240x216 you can fill nearly a third of the screen with unique content utilising 256 tiles. If a usage case arises that needs more unique content than this to be displayed then a bitmap mode becomes more appropriate. As Azure described, tile based modes are very convenient as once you have defined all the tiles your game requires you draw new screens be simply constructing a new table of tiles (or manipulating the existing table) to be displayed. The video chips back in the day when displaying tile based modes would fetch which tile was to be displayed (at any one time) from the table in memory. This tile number was then effectively became pointer to the actual tile display data itself (also in memory) which the display chip would then fetch and use to dynamically construct the scan lines as the raster progressed. This method makes no sense in a maximite where a DMA channel is feeding a SPI peripheral. Whether working in a bitmap or tile based mode in a maximite at a 'nuts and bolts' level the framebuffer and how it works would remain the same - it's still really just bitmap graphics - but the programmer doesn't need to be concerned with that. If the programmer defines their tile data and then works in tile mode where they manipulate an area of memory that represents the displayed tile table (through peeks/pokes or dedicated commands) and then maximite firmware adjusts the frambuffer so the changes are effected and displayed then it feels just like working in an old school tile based mode to the programmer. Tiles on old 8-bit machines were 8x8 pixels, presumably because this size matches the font size implemented in their text modes and thus allowed for efficient 'reuse of silicon' on the display chip rather than 8x8 necessarily being the ideal size. Personally I think slightly larger size of 10x10 would be better as this is still small enough to be flexible but you can then 'draw' more with the same number of tiles. Unfortunately use of 10x10 tiles dosen't fit with a 240x216 display resolution. Sprites behave the same in tile based modes as in bitmap mode. Tiles are just static graphic elements and are themselves not sprites and don't have any sprite logic associated with them. A tile once displayed is identical to any background element drawn in bitmap mode - a sprite may collide with a drawn tile and a collision should be detected. So implementing a tile based graphic mode should add no additional complexity to the sprite implementation. @Azure You absolutely correct with some hardware having the ability to independently scroll multiple planes. It is quite expensive from a memory perspective to be able to support this so it was never implemented in any 8-bit machine that I'm aware of. It became a common capability in dedicated arcade machine hardware however and made it simple for programmers to create some nice parallax effects as demonstrated in the acade shooter game Shienryu. Independently scrolling 2 planes - Shienryu -Heidelberg |
||||
| Heidelberg Newbie Joined: 22/01/2018 Location: AustraliaPosts: 13 |
Hi again, I just requesting comments and thoughts on a suggested strategy for perhaps dealing with video/graphics data. I noticed in the original maximite manual that the video frame buffer can be written to and read from using PEEK and POKE but the data is arranged in planed of RGB out of necessity. Being able to manipulate video data like this is certainly useful but being dealing with separate RGB planes is awkward and reminds me of coding for my EGA video card many years ago! Most old 8-bit computers shared RAM between the CPU and video chip - there was a one single address space. The MSX series were different, their video chips had dedicated RAM (VRAM) physically separate to CPU RAM. As expected all bitmap display data, pattern data and sprite data etc. existed in VRAM. VRAM could be read and written to using the VPOKE/VPEEK commands (in BASIC) which otherwise work exactly the same as their normal counter parts. How about creating a virtual address space for all video functions which is accessible through VPOKE/VPEEK commands? A memory map of this virtual address space could look something like this: *** Virtual VRAM map *** TOP->--------------------- SPRITE BITMAP DATA ->------------------------ TILE BITMAP DATA ->------------------------ TILE DISPLAY TABLE ->------------------------ BITMAP DISPLAY MEMORY 0 ->------------------------ RGB data could be packed so that two pixels fit into a byte: *** Pixel packing format *** XXLLLRRR X=Not used L=Left pixel R=Right pixel When VPEEK'ing from an area such as the bitmap area the maximite firmware automatically reads the required data from each RGB plane then packs the byte and returns it to the programmer. Conversely a VPOKE to the display bitmap, tile or sprite data area is automatically handled in firmware and the byte is depacked and copied into the required true memory locations for each plane. For simplicity keep the same packing format for RGB data for the bitmap screen buffer, tile data and sprites. Keep the virtual video address space locations constant then even with firmware revisions software would not break. When in tile based graphics mode the maximite firmware would automatically use data written to the tile display table area to update the actual true RGB planes in RAM. When in bitmap mode the data in the tile display table does nothing! What do you guys think? All video related data and structures could be kept neatly in a single virtual address space that could be manipulated with VPEEK/VPOKE commands or also additionally with other dedicated specialist commands. -Heidelberg |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
hi, with all this talk of how the maximum graphics performance was squeezed out of minimal hardware (literally, the minimum number of transistors), i find myself wondering if it would be better to instead concentrate on providing a set of graphics primitaves that have been created from scratch - without being driven by the old design goal of "the minimum number of transistors". after all, we are not constrained by 1980's hardware. in GFXterm i started out creating a few simple primative commands, with everything else built on top of that. the main one - seeing as it was a terminal emulator - was SCROLL: SCROLL( x1, y1, x2, y2, deltaX, deltaY) where (x1, y1) and (x2, y2) define a box area on the screen, and deltaX and deltaY indicated the direction to scroll in, and how far. would this sort of routine (along with peter's BLIT) not provide a good basis for many of the scrolling background games being discussed? it would also do much of the work needed for a game programmer to create their own software-sprites. this could then be combined with an extension to the timer tick system, by introducing an interrupt that triggers at the start of the VGA vertical blanking interval: SETTICK dummy, target, 0 there would be around 1.4ms available to do stuff [(525-480)/(525*60)] without interfering with VGA output, which with a bit of luck would be sufficient time for a single full-screen SCROLL or several smaller game object SCROLLs, along with a few small BLITs. how far would just SCROLL, BLIT and a VBI interrupt get us towards enabling easy game creation? cheers, rob :-) |
||||
darthmite Senior Member  Joined: 20/11/2011 Location: FrancePosts: 240 |
I have look arround but no chip with 100 pins have the integrated graphics controller.(and 32Mb internal SDRAM) I get the PIC32MZ2064DAG176 today  ... now i have to remember all PIC32 thing to look for make a fonctionnal board.Theory is when we know everything but nothing work ... Practice is when everything work but no one know why ;) |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1141 |
Hi Geoff, I know it's OT but will the new BIGMITE support the whole ASCII charracter set (e.g. german ÖÄÜß)? And maybe a second ASCII charracter for grapic charracters. Many of the old games are based on this. Kind regards Michael |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
I imagine the FONT command along with DEFINE FONT will allow for that with ease. For example, you could have a German ASCII font, and load that in at the start, and use that from that point on. Just need someone to generate the font file and/or DEFINE FONT code. [:)) Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 3 of 9 |
|||||
 Print this page |
