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 : Colour Maximite 2 - Second Generation
Page 3 of 4 | |||||
Author | Message | ||||
danielkos Newbie Joined: 10/07/2021 Location: AustraliaPosts: 25 |
I personally think this is a good kind of constraint. Perhaps keeping a few known/'stable' limitations is healthy on a platform where you want to encourage simplicity and a low barrier to entry for programmers in the long term. IMHO part of what makes the gen2 CMM2 great is that it provides extra features in a way that doesn't really diminish the value of the gen1. So people who are already happy with developing for the gen1 don't find themselves second-guessing whether they'll end up in a situation where their system has been made 'obsolete' by other programmers now taking advantage of higher specs that they don't have. There are case studies of great platforms that lost focus because their designers simply did too good a job of regularly up-spec-ing them. (The Apple II is a counter-example: in the 1980s, Apple deliberately kept glitches in the system between generations to give programmers long-term certainty that the platform was mostly set in stone. Building on stone is more satisfying than building on a moving foundation: you take more time to put quality into your code.) Some users will always cry out for 'more of x' and that can lead to a tragedy-of-the-commons type scenario that ends up sucking the spirit out of a platform. Weird related example: in my last job I did some consulting work on a proposal where we were thinking of purchasing a few hundred Raspberry Pis and associated hardware for use by university students. Big $$$ purchase, and certain key people in high positions really wanted to see it happen. The plan was that the hardware would be reused and kept for many years. We believed the Raspberry Pi Foundation's assurances that the model 3 would be supported for a long time to come, then they made a surprise announcement that a new much better model was being released. Even though the model 4 is backwards compatible, and the model 3 is still officially supported, this development muddied the waters enough that a satisfactory model for spending a few $100Ks on these SBC hardware purchases could no longer be agreed to, and a significant initiative ended up not happening nor being spoken of again. In that kind of scenario, everyone might appreciate how wonderful the new version of the platform is, the changes might be fantastic, but nobody ever hears of the cool things that 'never happened' afterwards so the blowback is unseen but it can erode the community over time. Anyway, just my 2 cents or maybe 5c since I've rambled on a bit too much! tl;dr: having imperfections and limitations in a stable platform isn't necessarily bad a bad thing and raising the specs just for the sake of doing so isn't always for the best. |
||||
MauroXavier Guru Joined: 06/03/2016 Location: BrazilPosts: 303 |
Final Fight currently has 285 kB, which are distributed in 27 INC files and one BAS file. This includes only the first stage of the game and I need to write one more enemy, five bosses and the other five stages, which isn't too big as the major logic was done already. I believe it can reach about 400 kB. The Into the Darkness I have no doubt that will surpass the 500 kB barrier but this can be solved using more than one BAS file with some transference area using external files. |
||||
toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 323 |
I personally think this is a good kind of constraint. Perhaps keeping a few known/'stable' limitations is healthy on a platform where you want to encourage simplicity and a low barrier to entry for programmers in the long term. IMHO part of what makes the gen2 CMM2 great is that it provides extra features in a way that doesn't really diminish the value of the gen1. So people who are already happy with developing for the gen1 don't find themselves second-guessing whether they'll end up in a situation where their system has been made 'obsolete' by other programmers now taking advantage of higher specs that they don't have. So you'd want to run 8-bit software on your 64-bit machine? If programmers can't take advantage of advances in hardware then why create new hardware at all? Sure I agree with backward compatibility to as great an extent as possible but don't keep developers from using all the hardware that's available to them! |
||||
bar1010 Senior Member Joined: 10/08/2020 Location: United StatesPosts: 195 |
I personally think this is a good kind of constraint. Perhaps keeping a few known/'stable' limitations is healthy on a platform where you want to encourage simplicity and a low barrier to entry for programmers in the long term. IMHO part of what makes the gen2 CMM2 great is that it provides extra features in a way that doesn't really diminish the value of the gen1. So people who are already happy with developing for the gen1 don't find themselves second-guessing whether they'll end up in a situation where their system has been made 'obsolete' by other programmers now taking advantage of higher specs that they don't have. So you'd want to run 8-bit software on your 64-bit machine? If programmers can't take advantage of advances in hardware then why create new hardware at all? Sure I agree with backward compatibility to as great an extent as possible but don't keep developers from using all the hardware that's available to them! I agree, constraints are like being behind jail bars. We would like to take advantage of advances in hardware. |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
Code size on the G1 is 512K. Code size on the G2 is 512K. Code size in flash is 512K code size in RAM is 512K. Same firmware for both G1 and G2 - not going to change, it is deeply embedded in the way the firmware uses memory Edited 2021-07-13 01:09 by matherp |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3807 |
If you want "more code" then chain multiple programs together or use the 512K to write a 'terp or VM (as a CSUB) and then put your "program" in RAM. Lots of room to be clever in . EDIT: with a VM plus a virtual memory implementation your only limit on "code" is the size of the SD card. Best wishes, Tom Edited 2021-07-13 02:04 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
bar1010 Senior Member Joined: 10/08/2020 Location: United StatesPosts: 195 |
EDIT: with a VM plus a virtual memory implementation your only limit on "code" is the size of the SD card. Best wishes, Tom Waveshare needs to offer a new board that has much more Flash RAM. Then this could be used for Generation 3. |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3807 |
I suspect the majority of CMM2s don't use a Waveshare board. In any case I believe the flash in question is built into the ARM microcontroller, or did I make that up? Best wishes, Tom Edited 2021-07-13 03:38 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1421 |
"Flash RAM"? Micromites and Maximites! - Beginning Maximite |
||||
bar1010 Senior Member Joined: 10/08/2020 Location: United StatesPosts: 195 |
Generation 2 says - A 1920x1080 pixel VGA mode and 24-bit colour. - More RAM for BASIC programs. Should read A 1920x1080 pixel VGA mode OR 24-bit Colour. The user can get one or the other, but not both at the same time. More RAM for BASIC programs is a LIE. The amount of RAM for coding programs remains 516K. It should read The amount of RAM for variables and general has been increased from 5,471K to 24,800K. This is false advertising. Edited 2021-07-13 08:49 by bar1010 |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3807 |
for coding programs remains 512K. This is false advertising. I know I should steer clear, but why would you say such a thing ??? There is considerably more RAM for BASIC programs to store variables/data and that is what this refers to. N.B. As originally conceived the CMM2 didn't use RAM for programs at all, it could only use Flash. I was concerned about Flash endurance and Peter was generous enough to listen to me and implement OPTION RAM. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 2989 |
Mighty strong language for what is at best a (mis) interpretation on your part. If my MMBasic program which used 5 megabytes for a serial port buffer can now use 24 megabytes, I'd say that is more RAM for my basic program. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
bar1010 Senior Member Joined: 10/08/2020 Location: United StatesPosts: 195 |
Mighty strong language for what is at best a (mis) interpretation on your part. If my MMBasic program which used 5 megabytes for a serial port buffer can now use 24 megabytes, I'd say that is more RAM for my basic program. I am really upset by the decision not to increase the maximum program code size. If I am going to pay about $200 for Generation 2 then it darn well better increase the maximum program code size, instead of having the amount of RAM for variables hogging most of it. Generation 2 could have been a much better product. |
||||
mclout999 Guru Joined: 05/07/2020 Location: United StatesPosts: 430 |
addition of hardware options that are very welcom. mather clearly explained the issue with the amount of code ram. The additional ram and the new graphics options will be leveraged by those with imagination enough to do so, Like MauroXavier's just-released "Colour Maximite 2 - Final Fight v0.5b" https://www.youtube.com/watch?v=xwFyvFUe528&ab_channel=MauroXavier-RetroDeveloper Check it out. It is very impressive. |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3422 |
Up to now I have seen functionality constantly increase on the micromite platforms. Thanks to Geoff and Peter. I can see gen2 CMM2 reach new heights if you give it time, and stay involved in a constructive way. This is hobby for 2 brilliant coders, surroundwd by equally skilled users and contributers. You could become one.... PicomiteVGA PETSCII ROBOTS |
||||
danielkos Newbie Joined: 10/07/2021 Location: AustraliaPosts: 25 |
So you'd want to run 8-bit software on your 64-bit machine? If programmers can't take advantage of advances in hardware then why create new hardware at all? Sure I agree with backward compatibility to as great an extent as possible but don't keep developers from using all the hardware that's available to them! Afraid I can't answer this in a short post. So here's a rather long post. I think your point is worth exploring, assumptions should be challenged, and it's hard to convey tone in writing so please don't feel like I'm ranting at you or anything like that :) Well first, we aren't talking about 8-bit. The CMM2 is a 32 bit machine. It's got high-colour modes and alpha channel graphics that never existed on 8-bit machines. As for the program code limit, selective loading could address that. But secondly, what makes you say that 64-bit is better? I know I'm very much a minority point of view (I have a different kind of background experience to other people) but 'bigger' doesn't mean more advanced despite what Intel's marketing team has led a generation of customers to believe. Bigger means bigger and that's all. For example: a V8 engine isn't 'more advanced' than a 4 cylinder with VVTi (but at one point in time, V8 was sold as the future of car engines). Thinking things through leads to better outcomes. 'Bigger' complicates things. We already know where the 'bigger is better' path leads to: it leads to the community needing to retrace their steps by inventing new systems like the CMM2 to try to go back to before things went wrong, just like the car industry retraced their steps and nowadays having more cylinders in your car is recognised as wasteful rather than 'more advanced'. As for why mainstream computing has gone 64-bit: well, I think that was a bad move. 32-bit was a 'sweet spot' and the industry has now stagnated as a result. 64-bit architecture on consumer devices has complexified hardware, cluttered up the assembly language, and created a QA support headache for vendors (who've since responded by breaking backward compatibility). The original flawed thinking was that 64-bit instructions were the only way to allow computers to access more than 4GB of RAM, since some engineers naively stated that if you couldn't represent a number larger than 4,294,967,295 in 32-bit binary then there'd be no way to represent a memory address outside 4GB without hauling the whole industry into a 64 bit world. (Likewise the same bigger-is-better reasoning in the internet world led to the ridiculous creation of IPv6 which will never succeed because it's insane, and because subnets make it unnecessary) The weight of boardroom groupthink at Intel and AMD, and some smoke and mirrors by their marketing gurus meant they were able to sell the industry the idea their way was the 'future', and leaner alternatives were 'the past'. Guess what? There are far better ways to address more than 4GB and extend your instruction set that don't overcomplicate your system in the way that 64-bit does. Memory address windowing is a perfectly fine solution, thus today's 32-bit software and Linux distros can address larger memory sizes just fine and hardware was never the obstacle (in fact engineering groupthink was the obstacle). In terms of instruction sets (the other reason for going 64-bit) Intel also tried to push a 64-bit instruction set that failed to take off (Intel Itanium: had some cool features but doomed to irrelevance) while AMD were smarter and able to retain 32-bit instructions with variable-width extensions. That move meant that AMD went from being a knockoff brand to being market leader and today's x64 Intel CPUs are now using the AMD system, so Intel went from being leader to follower due to their flawed 'bigger is better' direction. As far as I'm concerned (and I'm just speaking as a humble developer who writes long posts in forums! And I'm conscious of not wanting to derail the thread discussion too...), the CMM2 presents a chance to be more lean and clever and avoid repeating the galling mistakes of the mainstream (greedy-algorithm-driven) computer industry, which have been disastrous for software quality even though most developers and users have been led to perceive it as 'the way it has to be'. I don't know what kind of coder you are but surely the variable space is where you should be loading your megabytes of stuff into, and your program space should be kept small? Usually when someone complains about exhausting limits that seem like they shouldn't be exhausted that easily, my thinking is they have some kind of misconception that should be cleared up, rather than going to more drastic measures like redesigning the hardware. But for all I know you might be working on something extraordinary which does require more program space than variable space. |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3807 |
Great post @danielkos and I whole heartedly agree ... though I'm considered a bit eccentric in my views and approaches too . Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
|
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5645 |
IMHO the general ethos of these systems isn't really the hardware - that's what's available. You can't easily get a 8-bit SOC. :) The key ingredient is MMBasic - written to give the user the experience of using a pre-IBM PC home computer experience. It doesn't matter which platform you look at, that concept works excellently for all of them. Geoff & Peter have included various enhancements that have now stretched the original concept, but still generally held to the original concept. It was never intended to be an all-singing all-dancing ultra modern computer system. You can get those from any PC dealer relatively cheaply now. There's no real point to having over 512k of program space. That may sound ridiculous to some, but it's *program* space - this isn't like the early home computers where variables share the same space. You can (within reason and platform-dependent) usually forget about how much space your variables are taking up. 512k of *program* is huge - and often the facility is there to chain even more. Those who want to see over-expansion should realise that you are paying for the *hardware* only. If that seems expensive it's because the production runs are low in commercial terms. There's not a lot of profit made out of it. MMBasic and the ongoing support for it are provided without charge, incredible though it is. You simply can't get a better deal than that. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 323 |
So you'd want to run 8-bit software on your 64-bit machine? If programmers can't take advantage of advances in hardware then why create new hardware at all? Sure I agree with backward compatibility to as great an extent as possible but don't keep developers from using all the hardware that's available to them! Afraid I can't answer this in a short post. So here's a rather long post. I think your point is worth exploring, assumptions should be challenged, and it's hard to convey tone in writing so please don't feel like I'm ranting at you or anything like that :) Well first, we aren't talking about 8-bit. The CMM2 is a 32 bit machine. It's got high-colour modes and alpha channel graphics that never existed on 8-bit machines. As for the program code limit, selective loading could address that. But secondly, what makes you say that 64-bit is better? 1. I know the CMM2 isn't 8-bit. I was using that as an example of getting stuck with older technology. Would you really want to use programs written for 8-bit machines? No GUI, very limited memory? If developers didn't take advantage of newer hardware, that's where we'd be stuck. 2. My programs run faster and have more memory available to them for both code and data with 64-bit machines. I've benchmarked them against 32-bit versions. 'Bigger' complicates things. We already know where the 'bigger is better' path leads to: it leads to the community needing to retrace their steps by inventing new systems like the CMM2 to try to go back to before things went wrong, just like the car industry retraced their steps and nowadays having more cylinders in your car is recognised as wasteful rather than 'more advanced'. There are other considerations in the auto industry such as pollution and depletion of fossil fuels. These don't apply to computing so that analogy isn't quite apt. In computing, it's all about performance with little else to figure into the mix. As for why mainstream computing has gone 64-bit: well, I think that was a bad move. 32-bit was a 'sweet spot' and the industry has now stagnated as a result. 64-bit architecture on consumer devices has complexified hardware, cluttered up the assembly language, and created a QA support headache for vendors (who've since responded by breaking backward compatibility) How has going to 64-bit stagnated the industry? If we had stayed at 32-bit, now that would be stagnation. True, many coders seem to be lazier now. In my day (oh-oh here comes one of those stories from Gramps!) we programmed in assembly and had to fight for every byte we could squeeze out from the code. Now programmers can use C or whatever and don't really have to worry about machine resources. You need an extra 2MiB buffer? no problem! We would've killed for just an extra hundred bytes! There's no need to complicate anything in the 64-bit world. In fact, life can be much simpler for developers by just creating a single segment the size of memory. Then you can write your assembly language code the same way you did back in the 64K, 8-bit days. The only change will be the length of the addresses. Backward compatibility will be broken but sometimes that is the price we have to pay to move forward. Last of all, thank you for an intelligent, well-reasoned discussion. In so many forums, disagreements turn ugly and personal attacks result. I'm glad this forum is on a much higher level. |
||||
Page 3 of 4 |
Print this page |