-
Posts
31 -
Joined
-
Last visited
Profile Information
-
Gender
Male
-
Location
SC, US
petit chou's Achievements
Space Invader (2/9)
18
Reputation
-
IntyBASIC/JLP - guarantees on storage capacity?
petit chou replied to petit chou's topic in Intellivision Programming
Okay, this is super helpful. Thank you so much! -
IntyBASIC/JLP - guarantees on storage capacity?
petit chou replied to petit chou's topic in Intellivision Programming
That is hilarious. I thought I'd wondered about this before! Thanks for finding that for me. -
IntyBASIC/JLP - guarantees on storage capacity?
petit chou replied to petit chou's topic in Intellivision Programming
I've got it. Thank you so much. Do you happen to know what areas of memory are used by IntyBASIC? I've been looking at the memory map but I can't tell from the assembly output (my assembly skill is... questionable) what areas are being used and what are not. -
IntyBASIC/JLP - guarantees on storage capacity?
petit chou replied to petit chou's topic in Intellivision Programming
You have no idea how excited that makes me. Thank you! I know that Nostalgia at the very least supports the Intellicart standard, and it seems like it might be possible to hoodwink IntyBASIC into playing along with bankswitching by putting a label at the beginning of the initial memory for that area and just treating the bankswitched area like a gigantic array, but I don't have the technical know-how to check for sure. Unfortunately I don't know any of those developers, but this definitely seems like the right place to check! Maybe we'll get lucky and someone else around here knows them and could put you in touch. -
IntyBASIC/JLP - guarantees on storage capacity?
petit chou replied to petit chou's topic in Intellivision Programming
Sorry, I may not have been clear. I meant to say, if I don't want to use JLP features so that I can run my game in Nostalgia or Bliss, can I still use the extra RAM somehow from a modern board? -
IntyBASIC/JLP - guarantees on storage capacity?
petit chou replied to petit chou's topic in Intellivision Programming
Thank you for the response. A question: is there a way in IntyBASIC to access the extra RAM storage one of these carts would use? Would I need to manually declare an area as write-enabled with an assembly directive and PEEK()/POKE (or equivalent) at the memory locations? I'm trying to write a roguelike and need to hold quite a bit of information in memory to make the level states at least semi-persistent. I'd really love for my game to run in Nostalgia. jzintv is great, but my vision is terrible and its windowed mode only goes up to 640x480. -
IntyBASIC/JLP - guarantees on storage capacity?
petit chou replied to petit chou's topic in Intellivision Programming
This was absolutely amazing. Thank you so much for taking the time to give such a detailed and informative reply! -
Hey all, There isn't a whole lot of technical information on the JLP flashcarts in the IntyBASIC manual, so I wanted to ask some questions for clarification. I'm wanting to store some (overly) complicated data structures in the onboard flash memory and need to know some specific information: * Are FLASH.FIRST and FLASH.LAST guaranteed to point to the same place every time the cart runs? * Can I trust that there will always be a certain amount of continuous storage available on the cart? (i.e., will FLASH.LAST - FLASH.FIRST ever change?) * How fast are the FLASH READ and FLASH WRITE operations? Will it be approximately the same speed on real hardware as it is in jzintv? * Is using flash memory damaging to a physical cartridge over time or can I read and write as much as I'd like to without worrying? Thanks a ton in advance! (edit: fixed a typo)
-
That's much cleaner - thank you! I was just trying to get something up and working before worrying about optimizing it, although faster would probably be better. Right now it takes ~1/10th of a second to print a line, which is acceptable for this particular case (it's a roguelike - nothing is happening all that quickly) but would be nice to have faster for sure. I am having some really bizarre things happen to me if I use the routine to write a full row of text on the bottom -- I don't know if it's good ol' Intellivision quirkiness, an implementation issue in jzintv, something weird with the SCROLL statement or what. If I use BORDER and SCROLL the last two rows of the text in screen location 238 get eaten, but if I comment them out the problem goes away. Also there are strange graphical artifacts that seem to be happening if I write to screen location 239. I've attached a .zip file with the modified source (not with your optimizations yet, unfortunately) and the offending statements. Would you mind to take a look at them and toss me some ideas as to what might be going on? Thanks a ton -- you're amazing. petitchou - display weirdness.zip
-
Hey, all, I've been working on my own implementation of a halfwidth alphabet printer for my current project, a roguelike for the INTV. I am having an incredibly difficult time trying to diagnose an error I'm having in the stub program I intend to turn into my halfwidth print routine, and I could *really* use some help. The program is about 65 lines (not including the INCLUDEd data file full of BITMAP statements) and is attached to this post in a .zip file along with a compiled binary. The problem is somewhere in the math routines in my FOR loops -- it's pushing the right half of my text display ahead in the buffer a little too far, but I can't for the life of me figure out why. Any help you could give me would be so very greatly appreciated. Thank you so much in advance. petit chou - alphabet test.zip
-
IntyBASIC IntyBASIC Quick Reference
petit chou replied to petit chou's topic in Intellivision Programming
Here we go! PDF version, hot off the griddle. IntyBASICQuickReference.pdf -
IntyBASIC IntyBASIC Quick Reference
petit chou replied to petit chou's topic in Intellivision Programming
Aw! I hadn't even thought about it. Sure -- I have to fix a couple of small errors I've found in it, but that shouldn't be a problem at all. -
Aha! Thank you so much.