Jump to content

petit chou

Members
  • Content Count

    31
  • Joined

  • Last visited

Everything posted by petit chou

  1. That is hilarious. I thought I'd wondered about this before! Thanks for finding that for me.
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. This was absolutely amazing. Thank you so much for taking the time to give such a detailed and informative reply!
  7. 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)
  8. 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
  9. If I could hug you through the internet I would squeeze the stuffing out of you. Thank you SO much.
  10. 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
  11. Here we go! PDF version, hot off the griddle. IntyBASICQuickReference.pdf
  12. 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.
  13. When I compile the following code and run it, I get a strange (to me) result: MODE 1 #A1 = $0800 #A2 = $0816 PRINT AT 160 COLOR 7, <>#A1 PRINT AT 180 COLOR 7, <>#A2 WHILE 1:WAIT:WEND This prints 65535 twice. What's going on here? Is there something involving variable assignment that I'm just not getting? Thanks! (Edit: I'm using the --jlp switch.) (Edit 2: Compiling without the switch makes the error go away. Do I have to do something special to use the variable space afforded in the switch?)
  14. Seems straightforward enough -- I'll toss it all in there in a bit. If it looks cramped, it's because it started out as a thing for just me but I thought I'd share it if anyone else could get some use out of it. Thanks for the feedback! (Edit: Also, I didn't know the thing about RAND(). That's neat!) I moved the labelname bit closer to READ so it was clearer. The DEFINE thing would definitely be handy -- I'll add it in when I get a chance. Thanks!
  15. Hey all, I have no idea if this would be helpful to anyone else, but I thought I'd share it. I wrote a quick reference sheet for IntyBASIC because I kept catching myself paging back and forth between the manual and my work a lot. It's four pages long and definitely not a substitute for the manual's documentation, but if you're like me and like to print things out it might be useful. The link is here: https://docs.google.com/document/d/15rkNWb8at6ngUrI_q6qRIscpEizQxnL8gn7bZeLDEIg/edit?usp=sharing I don't know if my real name is attached to this or not (Google Docs is weird), but if it is please don't stalk me. This community is so wonderful. I hope this helps someone!
  16. Aha! Okay, easy fix - I'm surprised the compiler didn't complain about it though. Thanks!
  17. I am so confused. I am typing to compile a simple program (http://pastebin.com/wSdYfPAq) which appears to be causing IntyBASIC and as1600 to have a bit of a disagreement. I'll link the INCLUDEd file if needed -- it's just halfwidth alphabet data as a bunch of DATA statements with no execution. Anyway, IntyBASIC with the --jlp switch is processing it just fine: ...but as1600 doesn't like what it's outputting and won't compile it: When I look in the .lst file that as1600 generates for the error, a few thousand lines in I see the following: 50F6 0283 033F MVI _color,R3 50F8 0284 033E MVI _screen,R4 CALL PRNUM16.l alphabet2.asm:3216: ERROR - undefined symbol PRNUM16.l 50FA 0004 0100 0000 50FD 0244 033E MVO R4,_screen Does anyone have any idea what's going on here? I'm still trying to learn IntyBASIC but I'm absolutely baffled here. Thanks in advance!
  18. Hey all, Is there a (preferably clean) way to get a substring out of a string in IntyBASIC? I don't know if it's just a notation thing or what, but if it's in the manual I'm missing it. I'm hoping to implement a thin font implementation sort of similar to what GroovyBee posted a while back and it would be convenient for me to pass an entire string to a printing routine and pick it apart two letters at a time. Thanks a bunch!
  19. The little sound effect at the end sounds incredibly reminiscent of the sound effect that happens when the character dies in the Adventures of Lolo/Eggerland series. Is this a puzzle game? I'd love to see a Lolo reboot done up for the INTV!
  20. These responses are all amazing -- thank you so very much. Yeah, I think I might concoct some sort of simple RLE scheme for the map tiles -- it's not the best compression of course, but it's very quick and really simple to manage. This example was extremely helpful (thank you so much!), but I don't know if I can use this information for the contest or not. I'm under the impression that it needs to fit on a Bee3 board and I don't *think* they page from what I researched, although I don't know for sure. I know the contest rules don't explicitly state that it has to be playable on one, but the top prizes for the contest include having the winning game put on one of them and I want that game to be mine. (Actually, on looking closer, now I'm not at all sure. The post introducing the Bee3 is a little vague on the details given that it's an introduction and all, but it states the cartridge memory can be expanded. I have no idea how to go about coding for that though.) No kidding! I'll try to stick to the beaten path. --- You all are absolutely incredible and so helpful. Thank you again!
×
×
  • Create New...