 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 : firmware variants
  Page 2 of 3   |
|||||
| Author | Message | ||||
Nick Guru  Joined: 09/06/2011 Location: AustraliaPosts: 512 |
Ahh! Now you're thinking what I have been thinking! That's exactly what I'm trying to achieve...but without the celephane. 
This weekend, time permitting, I hope to have my 'digital cellophane' color addon up and running on my maximite. This mod will need a mod to the firmware to support it but it will only require 432 bytes of RAM, doesn't alter the operation of the MM and will cost less than $20 to make. ....if it works.  |
||||
| seco61 Senior Member  Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi Nick. I have also been thinking about how to implement this for the simple case of every character being able to have one of eight colours (including black and white!) and also the ability to invert the character. My current idea requires 1440 bytes of RAM and some interesting external electronics. How are you hoping to implement your colour scheme? Regards Gerard Regards Gerard (vk3cg/vk3grs) |
||||
| Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
Wow seco61! Good work! The fonts: I would move the entire character set to RAM and have it work as normal from there. The user can then POKE directly to any of the characters to redefine it. Better still, a BASIC command to redefine characters would be swish. Good idea about the ability to set integers. This was a common technique for getting extra speed back in they hey days of the TRS-80. Read/write binary files...yep! You could save the newly defined character set's and load whichever one you choose. You could have a whole library of typestyle, electronic symbols, game graphics etc. Hey! I like your thinking!  |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi Nick. Yes, I have a custom command to set the font, so no need to POKE. One of the issues with having the entire character set in RAM is the memory required to support this. With characters that can not be changed, they are defined as constant and get allocated as part of the program memory, as opposed to the more valuable "RAM" memory (and I know that RAM is not a good acronym to use!). If say a range of 32 characters were available to be altered, it reduces the impact on the memory. regards Gerard Regards Gerard (vk3cg/vk3grs) |
||||
| Gadget Regular Member  Joined: 22/06/2011 Location: AustraliaPosts: 70 |
I have extended the existing character to include "graphics" characters like the trs-80 (codes 128-191) leaving 64 free, so I created a second array to hold user definable characters, just working out a reouting to program these characters. I am thinking of creatting an array to hold the character codes and have the machine in the background translate that to data in the video array, am doing this to create a similar video adressing like the trs-80 so that a psuedo peek and poke command will read an display a character from video as opposed to bits. I'm doing this to allow me to convert the library of programs I have for the Trs-80/System 80 over to the Maximite. Regards Terry |
||||
| Gadget Regular Member Joined: 22/06/2011 Location: AustraliaPosts: 70 |
opps dyslexic fingers, should be a routine to program the characters |
||||
| Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
Already coded a command! Way to go!
I understand the memory issue, that makes sense. Still, the ability to change all the fonts would be cool. May be able to have a thicker font set to make a clearer display for LCD screens. (Probably not with an 8x8 matrix) How much program 'RAM' is available? I think the MM displays used memory as opposed to remaining memory. |
||||
| Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
Your method is much more advanced than mine. Mine is an ultra low cost solution that would rely on some changes to the firmware to make it usable. Mine basically changes the position of the single VGA line so it can be selectable in 8 combinations to the VGA connector. It would provide 8 colors but only 1 color (plus black) per video scanline. Only 432 bytes used max. Like I said, cheap and simple and probably enough for what the MM is to be used for. But yours is a much better spec. I'd go with your design if it doesn't involve too much modification to the MM. (Mine is to plug in to the 26 way IDC and VGA, no internal mods). |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi Terry. We have been thinking along the same lines. I also have some programs from the dim dark ages that utilised character graphics and commands to set and read characters. I was proposing to use VPOKE and VPEEK as the commands. I have had some brief email discussions with Geoff about this, and initially he was not keen on characters that are retricted to set locations on the screen (ie the 80 x 36 that MMBasic uses). However, due to his traveling, we have not concluded the discussion!! Again, the issue with having a lookup table for the fonts is that we have to reserve a byte of memory for each character position (another 2880 bytes). And if you want colour this grows again... Regards Gerard Regards Gerard (vk3cg/vk3grs) |
||||
| Gadget Regular Member Joined: 22/06/2011 Location: AustraliaPosts: 70 |
Gerard, yes i thought of the issue of memory space but am willing to make that concession. this method would limit the characters to fixed positions, but it still leaves Geoffs original method intact could locate characters by the pixel. Additional to this I am thinking of a method of grabbing a portion of a screen into an array and then being able to place this at wherever you want on the screen, kind of like a sprite. just some ideas as I am thinking of being able to use this little beast to run some games with basic animation capabilities. Terry next project is to interface the maximite to on of the speech chips I have (SP0256), lets see if i can make it speak. |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
While I have the firmware bits of my idea worked out (and programmed for a bit of fun!), I am still working on the external hardware. My current idea would require connection to pin 4 of the PIC32, as this provides the 20Mhz pixel clock and would be used to clock in the information to the external device, as well keeping the gating in sync (along with the h-sync and v-sync signals). I was intending to send the colour information for the current frame during the vertical back porch period (it would take just over 19 "lines" worth of time and the back porch is 58 lines). regards Gerard Regards Gerard (vk3cg/vk3grs) |
||||
| Gadget Regular Member Joined: 22/06/2011 Location: AustraliaPosts: 70 |
Well here is my contribution. Programmable characters usage: progchar character_number, pixel column 1,...pixel column 6 each character is a 6x12 matrix with each column stored as a 12bit value (if you were to convert each number to binary you would end up with a representation of the character on its side). characters available 192-255 example program: 10: CLS 20: PROGCHAR 192,1,2,3,4,5,6 30: FOR I = 32 TO 255 40: PRINT CHR$(I); 50: NEXT I 60: PRINT Also extra graphic characters have been programmed in the range 128-191 to emulate the chunky characters of the trs-80 2011-07-15_233205_Maximite.zip any comments let me know Terry |
||||
| Gadget Regular Member Joined: 22/06/2011 Location: AustraliaPosts: 70 |
opps found a bug character 192 wouldnt work, others seem ok try this one 2011-07-15_233927_Maximite.zip |
||||
captainbill Newbie  Joined: 16/06/2011 Location: United StatesPosts: 37 |
Howdy I was an old time TRS80 guy. There were many machine language routines written for it. TRS80 was an analog of the MM: a computer which only created, saved, loaded and ran basic programs. It had no "operating system" until an expansion interface (with 8" floppies) was added on. Z80 instruction set has relative addressing which allowed machine language code, correctly written, to be poked into string variable address space and executed. Early IBM PCs With just a DOS operating system had Qbasic, an interpreter similar to TRS80, also designed by Bill Gates, I think. The most common and perhaps most useful machine language subroutine was a mouse routine. It was self-relocating by use of relative addressing which is available in the 8086 instruction set. Please don't flame me if I am a bit fuzzy on the historical details. The gray hair on my head may have spread into my memory. I suppose all routines created by PIC32 C compilers are designed to be relocated by a linker. Maybe there is a way to cause the compiler to use relative addressing only. If compiled code subroutines cannot be used, a developer could resort to assembly language, explicitly making the code self-relocating, as in early TRS80 basic. With string space allocated and located by varptr it seems possible to poke the hex code and call it at its poked position. To keep things real simple arguments to the machine language routine could be poked into fixed offset locations within the allocated ram and return values could be similarly peeked at known offsets. A formal argument passing protocol would be better, but peeking and poking would work. For this scheme to work we need peek, poke, varptr and exec(varptr). The ML needs to be location independent and able to return back to basic's execution dispatcher. Piece of cake. But I could be wrong ;-) Bill p.s. It is hot as hell here. How is winter down there? Old school. Still interested. Head in the clouds. |
||||
James_From_Canb Senior Member Joined: 19/06/2011 Location: AustraliaPosts: 265 |
There's a bucket-load of space on the SD RAM card. Could it be used for virtual memory, or some form of swap file? And Bill - our Winter down here is freezing. I'll swap. I'm scraping frost off the car windows most days. There are regular -5 (Celcius) mornings here in our inland national capital sometimes getting up to a balmy 13. On the bright side, at least it's good for the snow season. James My mind is aglow with whirling, transient nodes of thought careening through a cosmic vapor of invention. Hedley Lamarr, Blazing Saddles (1974) |
||||
donmck Guru Joined: 09/06/2011 Location: AustraliaPosts: 1310 |
Hmmm.... Interesting concept. Won't have to wait to get up to speed, and no platters to crash. Cheers Don... https://www.32v8.com/1 |
||||
| Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
It's a Maximite for God's sake! There isn't any software written for it that uses half the memory it has! Virtual Memory?! That's PC'ifying the system. The main reason we have to have Virtual Memory is because of 'bloatware'. I remember when it started happening. Back in 1986, I saw the Mouse Driver for my DOS PC had become 80K in size! 80K!! To read a #$^& ball position and 2 buttons!? That's more program memory than what the MM has! Let's keep the Maximite lean and mean and stay away from the Dark Side. |
||||
| captainbill Newbie Joined: 16/06/2011 Location: United StatesPosts: 37 |
Howdy Lean and mean is what the MMB is, as Geoff has conceived it. It will be embellished, for sure. Additions to the core code should be general and universal in nature. However, many users may have need of hardware driver functions or other uses that don't fall into the general category. While it is true that a developer can recompile the entire MMB with his specific routines and then burn it into the PIC via the bootloader, I think runtime loadable subroutines are a more useful and elegant way to add to the language. When you need them for a particular purpose, you load them off SD data statement files or even data statements embedded in the basic program itself. While it is true that most hardware interface routines, or sophisticated math routines, can be written in MMB, certain functions may work better, if at all, as compiled (or assembley) ML code.They will almost certainly run faster. A facility to do this would be efficient and elegant. In a past life I was a hardware control, embedded code developer(flying jets is much cooler). I programmed in assembly, C, and pascal on 8051, z8000(remember it?), 8086 family. We used to compete for elegant code solutions. I would tell my coworkers that elegance isn't the only thing, but its not nothing. Beauty in a lover, spouse, or companion isn't the only thing. But its not nothing! Runtime loadable subroutines that, once loaded, work exactly like any other MMB statement is a very elegant way to embellish the language on a case by case basis without a recompile of the entire source code and bootloader update. Keeps the core MMB pure. More elegant to stick in a SD containing a zillion precompiled subroutines to be used whenever needed. I really believe in runtime loadable subroutines. I will now get off my soapbox. It was 100F degrees here today. Melted my tennies to the asphalt. Bill Old school. Still interested. Head in the clouds. |
||||
| Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
Well said 'captainbill'. I agree with you. This allows users to custom taylor their MM without making more permanant changes to the firmware. Allows the firmware to stay standard and not be fragmented with everyone's personal add ons. A linkable library for realtime interfacing or a library of graphics routines for Games. |
||||
stauros2 Newbie Joined: 17/07/2011 Location: AustraliaPosts: 2 |
I'm pretty sure she doesn't read this forum  |
||||
| Page 2 of 3 |
|||||
 Print this page |
