nonner242 Posted May 20, 2014 Share Posted May 20, 2014 Meh. Color is overrated. In my day, we didn't have any of that fancy colors you kids have. We played our video games on ruled notebook paper. We had one color, PENCIL, and we liked it. Shi... Screw you and your yuppie fancy ass ruled notebook paper ...you tech savvy young in. Back in my time we played our games with blood and stone. Until dinner time when it would all go into a pot for soup. There was no collecting back then, well other than poop and seeds....or was that seeds in poop? You guys have it so easy now. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 20, 2014 Author Share Posted May 20, 2014 I see your poop and seeds and raise you nettles and coal. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted May 20, 2014 Share Posted May 20, 2014 Shi... Screw you and your yuppie fancy ass ruled notebook paper ...you tech savvy young in. Back in my time we played our games with blood and stone. Until dinner time when it would all go into a pot for soup. There was no collecting back then, well other than poop and seeds....or was that seeds in poop? You guys have it so easy now. I must admit to never collecting poop and seeds. What do you call that hobby, crapbooking? Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted May 21, 2014 Share Posted May 21, 2014 By the way, Groovy, what does the 32K memory map look like? 1 Quote Link to comment Share on other sites More sharing options...
+Lathe26 Posted May 21, 2014 Share Posted May 21, 2014 By the way, Groovy, what does the 32K memory map look like? One 32KB map, coming right up: 32KB Map.bmp Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted May 21, 2014 Share Posted May 21, 2014 One 32KB map, coming right up: 32KB Map.bmp Cheater! You took that from the instructions, not from memory. 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted May 21, 2014 Share Posted May 21, 2014 Y'all are trippin and trollin' I got this! map.rom 2 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted May 21, 2014 Share Posted May 21, 2014 One 32KB map, coming right up: 32KB Map.bmp Wow! I never deleted a file so fast after download 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted May 21, 2014 Share Posted May 21, 2014 I actually wonder how my joke ROM would hold up on a real Bee3 board since it's 1k padded to 32k (obviously). Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 21, 2014 Author Share Posted May 21, 2014 By the way, Groovy, what does the 32K memory map look like? It doesn't . The command line tool I mentioned previously goes through the game's *.rom file and looks for ROM segments and chunks of RAM and then maps them were they are supposed to go. In the case of RAM it can only map as much as the microcontroller (also specified on the command line) can physically supply. If there are no RAM chunks defined in the *.rom file then the cart doesn't map them in. That means that you are free to have any memory map you like as long as the code and data in *.rom file takes less than 32K words. The only thing fixed is the I/O interface to the Bee3 "BIOS" but that could go on a command line switch if its not convenient. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 21, 2014 Author Share Posted May 21, 2014 Y'all are trippin and trollin' I got this! Nearly as much fun as Funbags! 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 21, 2014 Author Share Posted May 21, 2014 I actually wonder how my joke ROM would hold up on a real Bee3 board since it's 1k padded to 32k (obviously). If it works on a CC3 it'll work fine on a Bee3. 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted May 21, 2014 Share Posted May 21, 2014 (edited) It doesn't . The command line tool I mentioned previously goes through the game's *.rom file and looks for ROM segments and chunks of RAM and then maps them were they are supposed to go. In the case of RAM it can only map as much as the microcontroller (also specified on the command line) can physically supply. If there are no RAM chunks defined in the *.rom file then the cart doesn't map them in. That means that you are free to have any memory map you like as long as the code and data in *.rom file takes less than 32K words. The only thing fixed is the I/O interface to the Bee3 "BIOS" but that could go on a command line switch if its not convenient. So, if I understand correctly, if someone is using, say, P-Machinery and selects a memory map of 32K, it really does not matter which segments P-Machinery allocated for the ROM; your command line tool will re-map it as necessary. Is this correct? The reason I asked the question originally is because I want to build support for the Bee3 cart in P-Machinery 2.0. Right now, the framework supports 16K and 42K memory maps, which follows the "classic" mattel cartridge map and the JLP board, respectively. It seems that adding a 32K map for the Bee3 means just picking any available segments that add up to a maximum of 32K. P.S. The reason this is significant in P-Machinery is that the framework goes through some lengths in making sure the code fits within the allocated segments, and provides appropriate metrics to the programmer during builds. Edited May 21, 2014 by DZ-Jay 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 21, 2014 Author Share Posted May 21, 2014 So, if I understand correctly, if someone is using, say, P-Machinery and selects a memory map of 32K, it really does not matter which segments P-Machinery allocated for the ROM; your command line tool will re-map it as necessary. Is this correct? Correct! I don't want to force a memory map onto any developers if possible. The cart adapts itself to the *.rom image transparently. The command line tool will eventually morph into a Windows GUI tool at some point which will make it easier to use. That same GUI tool will program the microcontroller too . The reason I asked the question originally is because I want to build support for the Bee3 cart in P-Machinery 2.0. Right now, the framework supports 16K and 42K memory maps, which follows the "classic" mattel cartridge map and the JLP board, respectively. It seems that adding a 32K map for the Bee3 means just picking any available segments that add up to a maximum of 32K. At a guess, the only custom support you'll need will be to load/save data from the EEPROM. If you want EEPROM support then you need a small section of RAM so that the Bee3 "BIOS" can read/write data without going out onto the Inty's internal bus. However, I'll also be adding additional functionality like high speed maths and BCD operations down the line. P.S. The reason this is significant in P-Machinery is that the framework goes through some lengths in making sure the code fits within the allocated segments, and provides appropriate metrics to the programmer during builds. Sounds good. Although, as long as it says the segment is full then thats all the programmer needs . I have thought about making use of the fact that subroutines start/end points are marked with PROC/ENDP in the assembler. It'd be interesting to do a "best-fit" tool that tries to make the best use of available space by fitting functions together in each ROM segment. Such a tool is way, way down on my todo list so if anybody else wants to have a bash at it, feel free. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted May 21, 2014 Share Posted May 21, 2014 Correct! I don't want to force a memory map onto any developers if possible. The cart adapts itself to the *.rom image transparently. The command line tool will eventually morph into a Windows GUI tool at some point which will make it easier to use. That same GUI tool will program the microcontroller too . Cool! At a guess, the only custom support you'll need will be to load/save data from the EEPROM. If you want EEPROM support then you need a small section of RAM so that the Bee3 "BIOS" can read/write data without going out onto the Inty's internal bus. However, I'll also be adding additional functionality like high speed maths and BCD operations down the line. Understood. That I can wrap in a library, sort of what Joe has for the JLP, so that the programmer doesn't have to bother with the technical details. Sounds good. Although, as long as it says the segment is full then thats all the programmer needs . I have thought about making use of the fact that subroutines start/end points are marked with PROC/ENDP in the assembler. It'd be interesting to do a "best-fit" tool that tries to make the best use of available space by fitting functions together in each ROM segment. Such a tool is way, way down on my todo list so if anybody else wants to have a bash at it, feel free. P-Machinery defines specific segments and keeps track their usage, and alerts the programmer when a segment is full. The reason this is done is to ensure that procedures (PROC/ENDP blocks) are enclosed within the same segment. Otherwise, if the memory is not contiguous, the CPU will "fall through" unintended code. I don't know how this would work if the point of ROM allocation is done after assemblage. I would imagine this to be the work of the framework and the assembler, and part of the build process, no? -dZ. 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 21, 2014 Author Share Posted May 21, 2014 I don't know how this would work if the point of ROM allocation is done after assemblage. I would imagine this to be the work of the framework and the assembler, and part of the build process, no? If you add some extra @@ local labels with predefined common names to all the functions the tool could analyse the *.map\*.lst file and know the sizes of those functions in ROM. If the tool was provided with the desired memory map it could try to best-fit things and give a list of function for each ROM segment. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted May 21, 2014 Share Posted May 21, 2014 If you add some extra @@ local labels with predefined common names to all the functions the tool could analyse the *.map\*.lst file and know the sizes of those functions in ROM. If the tool was provided with the desired memory map it could try to best-fit things and give a list of function for each ROM segment. Sounds like a good idea. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 21, 2014 Author Share Posted May 21, 2014 Sounds like a good idea. Hmmm... Sounds like a job for a PERL programmer to me Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted May 22, 2014 Share Posted May 22, 2014 Hmmm... Sounds like a job for a PERL programmer to me Challenge accepted! 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 22, 2014 Author Share Posted May 22, 2014 Challenge accepted! Cool! Good luck on your mission! Quote Link to comment Share on other sites More sharing options...
Rev Posted May 22, 2014 Share Posted May 22, 2014 Will this Bee3 board be able to handle the awesomeness of Funbags! ....or will the board just melt. 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 22, 2014 Author Share Posted May 22, 2014 Bee3 will support all the Golden Girl games . Quote Link to comment Share on other sites More sharing options...
+cmart604 Posted May 23, 2014 Share Posted May 23, 2014 Bee3 will support all the Golden Girl games . Has Nonner finished the box artwork for the GG MegaGame Multipak?! 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 23, 2014 Author Share Posted May 23, 2014 The reason I asked the question originally is because I want to build support for the Bee3 cart in P-Machinery 2.0. I've been thinking about this and I'll add functionality to the Bee3 BIOS so that it writes some magic values to its on-chip RAM. That way the Inty "API" can check if the values exist in RAM and if they do it can make Bee3 "BIOS calls" to handle EEPROM data read/write. However, if they don't exist then those same routines can just return an fake "error" of some kind. That way the game will still work on CC3, jzintv etc. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 23, 2014 Author Share Posted May 23, 2014 Has Nonner finished the box artwork for the GG MegaGame Multipak?! Yes! Its life sized! Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.