Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

7 Neutral

About evildead9000

  • Rank
    Space Invader

Profile Information

  • Gender

Recent Profile Visitors

601 profile views
  1. Just joined. Awaiting approval. Thanks much!
  2. Hello all. A while ago I watched the following tutorial on EPROM burning for a Bally Astrocade game: As per the following link from BallyAlley, ICBM Attack and Treasure Cove are public domain: https://ballyalley.com/ballyalley/articles/two_astrocade_pd_programs.html I would like to attempt to create a cartridge of Treasure Cove for personal use. Can anyone recommend an EPROM burner that works with an MCM 68764 or compatible chip? As per the video, 25v is required to program the chip. I'm looking on Amazon and found one that seems a good price that I think works with the chip: https://www.amazon.com/gp/product/B01212KD74?pf_rd_r=H0VR3YKMYFWZSFJYDVBS&pf_rd_p=edaba0ee-c2fe-4124-9f5d-b31d6b1bfbee I asked the seller, but he could not confirm whether it worked with the chip. This was his response: "I have been using this to program the Intel 2764 eeproms for 80s vintage Bally Sterns pinball machines and I am very happy with it. It even does the older 2716 with 25v program voltage requirement. I believe there are a few compatible 2764 devices you can use in the Bally Sterns but the may have slightly different programming requirements (voltage and timings)." I also contacted the person who posted the EPROM Programming Tutorial. However, he could not recommend any modern burners because he still uses a much older burner, which uses a parallel port. He then directed me to this forum for assistance. Can anyone confirm or recommend a good model? Thanks much! Long live Bally!
  3. Since I know how many lines of data there are I added a loop. I made three data lines for testing purposes. I omitted the error and status checks to save space. This is what I have now: 10 dopen#1,"level1",d0,u8:print"{home}" <-reverse heart to clear the screen 20 for c=1 to 3:input#1,a$:print"{up}"a$:next <-moves the next print up, so there's no extra line in between data It prints the map from the very top of the screen perfectly. The SEQ file is fine (thanks again!). It appears the line with the ST check is ending the code after 1 pass. I re-checked my typing and it looked good; unless I need a new monitor and or glasses! :-) I've been using CBM PRG Studio to create my program. There I ran my code and it automatically launches xpet(from Vice). One major thing (which took me a while to figure out) was that for some reason it launched the emulator as a PET 8032 model. Very odd since it's been launching as 4032 ever since I've been using it. It's been a busy day and I wanted to further test and reply sooner, but couldn't. I'm happy that it's working exactly as I need it. Perhaps, it doesn't work on an 8032? Also, when my game opens in that mode it doesn't fully work either. I've tested my code on my real PET with a PetSD and it's all good so far. In the future I will be purchasing a real drive. Thanks much for all your help and everyone else too; and for following through with great advice. I really learned a lot.
  4. Okay, before I jumped the gun. It was reading the data correctly with no added characters, but only one line. I checked the SEQ file in DirMaster and the entire map shows. ST is not 64(end of data status), so it should loop. I do appreciate the simplified code, which is much easier to understand. My game code gosubs to the code snippet above that I added. The only line I modified was 50, which I changed to return, so it returns to the game code after the level loads. And of course I changed the gosub number in line 20 to match the changed line number. At this point the first data line of my map appears and the game continues where it left off. Any ideas what I may have done wrong?
  5. Yes, my keyboard has the fours columns of numeric on the right. My original SEQ file looked like this: 10 data 120,120,120,120, etc. I redid it as you suggested; with quotes and my map characters within. Now it reads the entire data line in one pass. Thanks all!
  6. I have a Commodore Pet 4032 with Basic 4.0. I believe I successfully wrote the SEQ file. I loaded it in DirMaster and it is showing as a list of 102, which is the character I'm using for a wall. However, when I try to read it, it only prints once. Print a$ is printing the number 102. Poke32768, val(a$) prints the character I need. I checked my code for typos a few times and I'm not sure why it's not printing/reading all of them. Thanks for the quick reply!
  7. I've decided it's best to access the map data from a disk. You're totally correct. Space wise of course it's better, but I mainly want to design the maps/levels instead of something random. Instead of similar levels randomly generated, I would like many levels that differ with total control of their design. I would never get that without accessing from a disk. This is my test that I attempted: 10 open 5,8,5"level1,d0,r" 20 get#5,t$:print t$ <------I tried to use Input, but couldn't get it to work. 30 if st<>64 goto 20 I'm not familiar with storing the data as a PETSCII txt file. level1 is a prg file and has only 2 lines of data: 10 "---------------------------------------------------------------------- 20 "( ) I substituted characters, but basically it's the top and side walls of a dungeon. The syntax is incorrect, but I am able to store the data as is trying to be economical. I do plan on storing other data on the disk, not just maps. Instead of cutting stuff out to make it work within the memory constraints, I'll keep as much as I can in and go for it! When I run the code above, it does work, but I'm getting extra characters and I'm not sure why. Initially I had them as data statements and the string in quotes. I also had numbers, which I used as poke values: poke32768+c,val(t$). It worked fine and I incremented c, but I also got extra characters. Is there any big difference between printing it to the screen or poking it? I'm off the mark and any further guidance would be much appreciated. Thanks!
  8. 16K is crazy! However, there are still some good 16K games too!
  9. Great advice! I did think about storing the levels on disk, but I'm going to try and avoid doing so. At this time I have a few ideas to randomize the levels a bit, but have yet to implement. I also may not randomize; I'm not quite sure yet. We'll see how it goes. I'm at 8k now, but already know a bunch unnecessary stuff to remove. However, I may need to utilize your suggestions! Time will tell. As always, thanks much!
  10. My original Commodore 64 was in my basement and that's where I played it growing up. Usually with the lights out late at night. The music was intense! The death scenes were always jarring and sudden, and scared the crap out of me! You should definitely play it in the dark...late at night...with headphones!
  11. When I finally defeated the four headed dragon at the end of Beyond the Forbidden Forest (and wasn't burned alive)!
  12. True! I should've thought about that! Now at randomized placement I will store the locations. So with both coordinates what would the simplest next step be? Is the rest of my logic above decent or too many steps?
  13. Hello all once again! I'm not quite sure how to go about implementing my next bit of code, but here goes. I have two characters on-screen; let's say A, which is at the top left of the screen and B, which is in the center of the screen. The player enters an angle to fire a projectile; let's say 45 degrees. I would like another character to appear, as if were fired by letter A, at said angle toward B. Kind of like an Artillery Duel of sorts. (the game where two cannons fire at each other from different sides of the screen using angles.) However, if the angle is incorrect the projectile will miss B. Afterwards, B will move closer to A. I was thinking that I would need to create a peek loop to check all chars on screen (or of a specific area) until A is found, then repeat for B. Once both locations are collected, get the angle of B in relation to A. Afterwards, the projectile would be poked into a location next to A and move toward B at the angle the player entered. Whew! With that said, I'm not sure I'm in the right ball park of how to implement. Please provide some feedback as to whether this is a decent approach and if not, let me know a better one. I think once I understand this, I could really move forward with my code. So far I've tested numerous different parts and have made okay progress. Thanks much! Also, is it possibly better to first get line coordinates from A to B (as if to draw a line from one to the other) to obtain the HIT angle? Then draw another line from A toward B at the angle the player entered.
  14. Wow indeed! Great stuff! It'll take me a bit to process all of it, but it's starting to click! Thanks to all who responded. And if anyone has any more info to add, I'd gladly read every word! Thx!
  15. Great info! I was on the right track. I was concatenating a lot and reusing counter variables. Now I'll truncate some words as well, so instead of "MAGIC", I'll use "MAG", or even just "M". I'm also omitting many spaces, so instead of PRINT T$, I have PRINTT$. Definitely in my loops too and every other place possible! 🙂 However, I don't quite follow: " store maps as raw data into memory instead of variables - think POKE/PEEK an area of 40x25 bytes instead of string variables. " Can you please clarify?
  • Create New...