Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

awhite2600

Members
 View Profile  See their activity

  • Content Count

    363

  • Joined

  • Last visited

Posts posted by awhite2600

  3. Posted

    I suspect that multi-track recorders weren't used due to possible issues with head and tape alignment. If a signal was split into two or four parallel tracks then even the smallest misalignment could cause read errors.

     

    Mainframes used 9-track tapes to store data. (These are the big computer tape drives that you always see in movies.) These drives used complex tape paths and vacuum columns to work reliably. This level of complexity would not have been cost effective in a consumer product.

  9. Posted

    That´s interesting, I didn´t know about the "LipStik Plus". Did it work well?

    My memory from back in the day is a bit fuzzy. I think a friend of mine had a "LipStick Plus". I recall that it was little more than a voice activated fire button. You would play a game and yell, "Fire" to shoot. You could have yelled "Pizza" or "A**h**l" and it would still shoot. I think he even had a pirated version of one of the voice games that was hacked to use a regular joystick.

    • Like 1

  10. Posted

    Driving external hardware through the I/O ports of a computer has so many possibilities. When I was in high school in 1985, a fellow student and I used a Commodore 64 to drive six Kodak Carousel slide projectors. Not only could the interface change the slides, it could turn the lamps on and off. We built an interface board that used 8 bits from the user port and 4 bits from one of the joystick ports. We even wrote a scripting language, compiler and runtime environment to allow us to create a complex slide show synced to music. I found the slideshow on an old Beta tape and uploaded it to YouTube. http://youtu.be/WbOrx0rczFk

  14. Posted

     

    Hmmmm... I don't have tested it. I suppose you should keep track of position.

     

    I was so happy that it worked that I forget completely about MOB.

     

    Not a big deal. I would figure it out quickly enough.

     

    My (bug filled) code already does smooth scrolling and MOB updates via pokes. Based on your comment I guess the MOBs will scroll with the screen if left untouched. I'll just keep my existing MOB position code in place and sub the new SCROLL command in where my bug filled scroll routine is.

    • Like 1

  15. Posted

    Thanks nanochess. I look forward to installing IntyBASIC v0.5 and testing it with my game code. Native SCROLL support will be a big help.

     

    Does the native scroll support keep MOBs stationary on screen or do they "scroll" with the background? My game currently requires that the MOBs stay still. If the SCROLL command moves the MOBs then I will just update them to appear in place.

     

    I haven't had a chance to work on my game since the weekend. Going to try to get back to it again tonight.

  16. Posted

     

    Another option, if you have the RAM for it, would be to construct your entire "world" in an off-screen buffer. Then, instead of scrolling, you're copying a window of the world onto the display. That can be cleaner to code and still very quick. Even if you have to copy the window to the display every frame, that only costs around 4500 cycles from assembly code, IIRC.

     

    To make that practical, you probably have to use a memory map that adds more RAM (such as the 42K map in cart.mac).

     

    I'm not certain what memory maps are supported by IntyBASIC. I'd also like the option to be able to have carts produced. (I realize that this is not easy.) I believe that larger carts or those with RAM are more difficult/costly to produce.

     

    There is no "world" to the game that I am designing, I'll describe it for now as a simple side scroller. New elements will enter as the screen scrolls. As some of the objects entering the screen are large, I just need to keep track so that they can be drawn over multiple columns of cards. Nothing too difficult, just takes some thought into the best way to do it. I haven't written a game since the early 90's, so my programming skills are a bit rusty.

  17. Posted · Edited by awhite2600

     

    BTW, one way you can make this work more smoothly, if you have the RAM, is to compute the new column way ahead of time so it's ready to go at a moment's notice. If you're using cart.mac and the 42K memory map, you have 8K words of RAM available to you, so you could use that.

     

    That said, the display is only 12 rows tall, so burning 12 words of System RAM (or 24 words of Scratch RAM) may be acceptable also.

     

    My understanding is that IntyBASIC outputs assembly code. (Shamefully, I admit I haven't tried playing with it yet.) So, you should be able to find your copy loop and count cycles there. For something as basic as a "slide row left 1" and "slide row right 1", there's not much advantage to writing that in BASIC, so it's probably worth figuring out how to patch those in as unrolled assembly functions.

     

    Here's a couple routines I just whipped up that you're welcome to use. Untested, but they look correct.

    ;; Slides a row of cards left by 1.  Does not modify rightmost card.
;; Pointer to start of row in R4.
;; Modifies R0, R1, R4, R5.
;; 348 cycles.

......

    Thanks for the code intvnut. I'll likely try some test scrolling code in BASIC. If the scrolling "works" (scrolls without corruption) then I may attempt to wedge your assembly version into my game. Using a true scroll routine vs. a complete redraw will require me to rethink some of my code. The screen is constructed algorithmicly at this point. While it will be more efficient to just draw the new zone after a scroll, it will necessitate some major code changes. The good thing is that the changes will likely allow me to drop using a couple of arrays to store/calc the screen state.

    Nanochess has indicated that he might include a scrolling routine in his next release - so that could end up being an option too. Nanochess, do you have a plan for your next release? Any other features, changes? Do you have an approximate timeline in mind? (I'm not pushing. I think IntyBASIC is great. )

  18. Posted

    Thanks for the detailed explanation intvnut. It was quite helpful.

     

    As I said, my code is not even close to being optimized. That's likely a big part of the problem. Currently, I recalculate and redraw the screen - shifted one card to the left. There are a couple of nested loops and some other code required to do the "recalc". So I'm likely way over the number of cycles used by the STIC to draw the screen. Artifacts aren't even the issue, the screen is getting corrupted the more it scrolls.

     

    I'm going to rewrite the scroll routine to do a peek/poke memory copy. That should shorten the number of cycles considerably. I'd take a stab at writing the scroller in assembly, but I want to walk before I run.

     

    Due to the fact that I'm using IntyBASIC I have no idea how many cycles are being consumed by various sections of my code.

     

    As I write this reply I've come up with some ideas to optimize the screen draw routines. It's unnecessarily complex at the moment. If I can reduce the complexity and write a better memcopy style scroller I should be in better shape.

  19. Posted · Edited by awhite2600

    I'm starting to write a game in IntyBASIC. I'd like to keep the game secret for the time being. I may release the game once it reaches a playable state. For now, it's just an experimental concept.

     

    I'm new to the world of Intellivision programming - despite owning an Intellivision since 1982 and writing programs since 1980. I'm trying to get my head around the hardware and some of the limitations.

     

    The game requires smooth horizontal scrolling. I can draw the screen and then scroll it back and forth 8 pixels without any issues. My scroll routine uses the hardware to to the fine scrolling. After 8 pixels I essentially redraw the entire screen shifted by one card. (I may be able to optimize this, but for now I update all of the cards by poking directly into the BACKTAB area.) The screen becomes corrupt after a while. This might just be a bug in my scrolling code.

     

    Another thread mentions updating less than 20 cards at a time. Is this a limitation of the hardware (or timing)? Should I try to optimize the scrolling to do more intelligent redrawing?

    • Like 1

  20. Posted

    Below is a chronological list of systems/computers that I still own that were purchased "back in the day" when they were "current".

    • AFP TV Fun (Pong clone)
    • TRS-80 PC1 Pocket Computer
    • Intellivision (original version) Purchased by my parents. Still have the unit and most of the games - plus lots more that I have accumulated since. Sadly, the Intellivision stopped working when it was a few years old. I replaced it with an INTV III but kept the original for parts.
    • Commodore 64
    • Amiga 1000
    • TRS-80 PC6 Pocket Computer
    • GameBoy (1st version) Purchased the second day it was available in Canada.
    • Atari Lynx
    • TG 16
    • Sega Genesis
    • Famiclone (Micro Genius IQ 501) Purchased when the NES was still somewhat current. This is a true Famiclone, not a NOAC.
    • PS1 Purchased in it's day for my son...he's since moved on to newer stuff.
    • XBox (original) Received as a promotion when working for a Microsoft Partner.
    • PS3
    • DS Lite
    • PSP Go

    I have lots of other systems / computers that have been purchased on the secondary market. Commodore PET, Commodore VIC-20, Atari 2600, Atari 7800, Colecovision and ADAM, SNES, N64, pong clones. I also have a bunch of handhelds many of which were purchased "back in the day".

  21. Posted

    It was (and probably is) fairly common that mainframes and midrange machines had more inside than what you thought. Often it was easier to just ship the full capability box and enable what the customer had paid for, so some upgrades were just as simple as enabling the extra hardware.

    In my experience though, it was usually main storage (aka RAM) and CPUs (multiprocessor mainframes were pretty much the norm by the 80s).

     

    Additional to that, a lot of equipment was leased anyway, so essentially it was the manufacturer's property which you were paying for the use of.

     

    It's similar today with the ERP (accounting) software that I support for my job. Most of the modules and functionality get installed by default. A client receives a registration key that activates the functionality and users that they pay for. If a client wants additional features or users we just send them a new registration key. (i realize that you can't truly compare hardware and software - just making an analogy.)

  22. Posted

    Does VirtualBox have extensions for Windows 95? If so, that would provide the necessary drivers for higher resolutions. There may still be limitations.

     

    I wouldn't put the virtual hard disk on a flash drive. Flash drives have a limited number of write cycles before the flash memory will start to degrade and fail. While it may appear to work you will slowly kill the flash drive. Performance would also be quite bad as flash drives are slow to write to. Put the virtual hard disk on a hard drive. You can make a backup on a flash drive.

  24. Posted

    I used to use Turbo BASIC quite a bit in the late 80's / early 90's. Sadly, It's been a while since I've had to use it ...

     

    I believe that the $COM1 and $COM2 settings are used to set the buffer size for serial port communications.

     

    I don't remember there being a 256 byte limit on strings. You should be able to easily do a test. Declare one string variable with a value that is about 200 characters. Assign a second variable to be equal to the first. Then concatenate the two together (into one of the variables or a third one) then print the contents. If the result prints the entire concatenated string then there is no specific limit.

  25. Posted

    I have one of the original TRS-80 Pocket Computers - the PC1. It was my first "computer". As a 14 year old who's only source of income was a paper route, it was all I could afford. I couldn't even afford the cassette interface. I did manage to pick up the printer/cassette interface years later when they were on clearance.

     

    I stretched that little computer as far as I could with it's 1424 "steps" of memory. The BASIC had some serious limitations but also had some unusual strengths. I did all sorts of creative things with calculated GOTOs and the strange ways you could use variables in one big array. I spent hours adapting and condensing programs for other computers to run on the PC1. I even went so far as to use the PC1 to cheat on some high school exams. Most of the exam supervisors thought it was a fancy calculator. Little did they know that I could store cheat notes as programs.

     

    I also have a PC6 with the memory expansion unit. I bought the PC6 in the late 80's thinking that it would be a fun toy. Radio Shack advertised the PC6 as being programmable in assembler. I had visions of creating cool assembly language demos, hitting the hardware to make the computer do unusual things, etc. I was seriously disappointed when I learned that the assembler was just a "simulator" within a protected environment and nothing more than an educational tool.

     

    I still have both computers packed away. Both need batteries but still work perfectly.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...