Index: 0:00 Intro - VIC-20, Timex/Sinclair 1000, ZX81 1:23 Tenliner Cave Adventure port for VIC-20 3:54 A bit about the Timex/Sinclair 1000 6:28 The original ZX81 version of Tenliner Cave Adventure 8:42 Porting the game from ZX81 to VIC-20 21:57 Jason Compton’s port to ZIL 26:24 Running the ZILF port on VIC-20 27:36 Timex/Sinclair 1000 Outtake 1 34:31 Outtake 2
I had the timex sinclair 1000 with the 16k ram as my first computer. so we share same.. I skipped the vic 20 and got a c64 instead. then 128 flat and 128d .
when i was 12 i made a text based game that used the tape drive as a kinda extra memory like datbase that one could ask using the syntax ask questions and do things...it lead with its graphics ability to me making a kinda of romans vs vikings video game ( ya i know they did not exist at same time but ya was fun as a kid) took quite some time to figure out all the graphics of poking and peeking and moving things around ina kinda turn based war game you had mini adventures in. the crap we had to invent just to have fun back then....
The ZX81 was my first computer, too. Typed in a lot of programs from the back of magazines. The Sinclair also had a cleverly engineered 16k RAM module that attached to the back. It was perfectly designed to remain securely fastened to the interface until the final moments before you completed the entry of your 15,000 character chess program, as which point it would fall off, short out everything, and your program would evaporate into the silicon ether.
There's a reason for that--in order to cut costs they used the same RAMpack for the ZX81 that they did for the ZX80, rather than designing a new one for the machine. Thing is, the ZX80 had a nice flat back which the pack nestled against snugly, but the ZX81's was angled, meaning the only thing holding the pack in place was the edge connector. Hence RAMpack wobble and its attendant annoyances!
@@d2factotum Yep. I used to hold it in place with a piece of Duct tape. I also used a piece of picture framing wire to hold the power cord in the socket. Frankencomputer.
@@d2factotum This thing was apparently all about cutting costs. Bad keyboard, extremely limited memory, wonky display, no sound, and expansion RAM module falling out? What an utter POS, even for the time. I'd bet the bulk of its "sales" (especially in the USA) were simply to trade it in to get the $100 Commodore 64 rebate! Honestly, IDK how Sinclair even prospered, even looking at the ZX Spectrum (the color pallete is horrific, just rainbow, really? And the sound is a joke.) the C=64 blew it away. I guess poor Brits didn't care that they were using a piece of shit, as long as it was cheap.
@@SeeJayPlayGames it's easy to judge, but Sinclair made basic computers available to low-income households and whilst they may be a joke to you they inspired several generations (myself included) that would otherwise never have had access to a home computer.
The tokenisation on the keyboard of the spectrum was actually a great way to learn basic. I remember as a kid in the 80s when I began learning to program basic all I had were a few books of pre made programs to type in, so having the complete basic command set on the keyboard allowed you to experiment with things you didn't know or fully understand.
I never had any of those computers, although I knew they existed and used a few when they were on display in computer/electronic stores. But some of the discussions here remind me of a neat trick I used in GW-BASIC for DOS, to speed up saving and loading game data in a particular game which I ported from the TRS-80 CoCo... The game used a large integer array to hold game data and it needed to save and load that data whenever the player "changed levels" (something similar to how some FPS video games have to pause to load a new area when you hit a switch to go to the next stage in the game). Originally, this game saved and loaded that data by sending it to a sequential file, one array element at a time, and then loading the target level in from a file in the same way until the whole array was saved or loaded. I sped up this process by using the trick of finding where the array started using VARPTR(ARRAY(0,0)) and then multiplying by the x and y dimensions (plus one for each because they both start with zero, not one) and then multiplying by 2 since integer variables occupy 2 memory spaces, then I used BSAVE and BLOAD (Binary Save and Binary Load), which each took a fraction of a second instead of the 30 seconds or more which would be required if I used a sequential file. The format was BSAVE"filename",start,length and BLOAD"filename",start (the length was optional and if not provided, the whole file would be loaded). Rough example from memory: BSAVE"LEVEL1",VARPTR(ARRAY(0,0)),(X+1)*(Y+1)*2 This only worked because the array was always exactly the same length. Even after all this time, I think it was my "neatest trick" in GW-BASIC. I kind-of miss those days of exploring the limits of both hardware and software.
I once tried to make a text adventure on MSX in such a way that you wouldn't get spoilers while typing in the listing. It had an actual line parser which gave certain words certain values so that adding up those values would quickly descern if your action was possible. The actual text in the listing was split up in syllables each with their own value, so that every syllable had to be in the listing only once, and the sentences were only a string of numbers (spoiler free listing!) I never finished it, though. Maybe I should take it up again someday. It was fun to do.
My first computer was also a Timex Sinclair 1000--and I loved it because a simple computer is far better than no computer. Next, I got a Commodore 64, and I could truly appreciate its power.
The C64 BASIC's support for READ/DATA, along with multiple statements per line, would allow the game to be condensed to about 2 lines of executable code, followed by DATA statements for everything else. I haven't tried to work out how many 80-character lines of data would be required, but I think it would likely come in less than 8. An adventure I remember for the VIC-20 when I was growing up had five rooms, an inventory limit of three items, and a pirate, and magic beans. One had to get three chests to the start room, grow a beanstalk, block the pirate, and climb the beanstalk to win. Does that ring any bells for anyone?
Possible simplification of the multiple-AND line. Use * instead of AND, it's slower but takes less characters. This is actually a trick I learned from Excel spreadsheet experts and it works in BASIC too.
You enter a room and (gasp) new hand appears - great to "see" Jason! I entered that 10 line BASIC contest in 2016, it is really hard and a lot of work. Another great episode!
Man...I am so glad youtube suggested your channel and specifically this video to me, for more than a few reasons. Firstly, the VIC-20 was the first computer I had as a kid. Secondly, I live in FL, not too far from Longwood, the original location/HQ of "Adventure, International". Never got to the store, though, but once and it was well after AI's heyday. I don't believe Scott Adams was in the shop that day. But speaking of Mr. Adams...Adventureland was one of the first games I owned for the VIC, and at the tender age of around 13 or so I found it to be very difficult. The Count and Pirate's Cove were much, much easier. Also, the famous "SYS 49152" command used to start the adventure always intrigued me as a kid...so much so that I would often try different addresses to see what would happen. They broadly fell into one of three categories: an error from the VIC-20, the VIC-20 locking up completely and having to be turned off and back on, or just throwing out random gibberish. However, one day I entered a number and it caused a hint file for Adventureland to be displayed! I wrote everything down on a notepad, then started the game and followed the hints, and finally won! For some reason, memory of the "help text" dump was going through my head and I found Scott Adams' current email address and asked him about it, and we corresponded a bit about it. He was as surprised as I was that it had done that, but as far as he knew the only thing like a large "hint file" were different responses you could get from the magic mirror (one of the treasures you had to collect in the game). So I guess I hit just the right address in the code to make it "run" and spew out that file. The other thing is...I remember Jason from Amiga Report back in the 90s! I doubt he remembers me, but I was one of the legions of fans of his, and used to hang out on amiga-centric IRC channels back in my early 20s, communing with him and other fans of that platform. Anyway, so glad I found your channel! Consider me subscribed!
When I was about 12 (about 1982) My brother got/bought a TS-1000 from a friend. I utterly fascinated with it and I think what really attracted me to it were the programming commands (and the graphics) on the keys. Those coding keywords sparked my imagination and I wanted to learn to program it. Of course, it was my brothers so he didn't want me touching it. So my parents bought me a VIC20 and soon later a C64. Well, these years later I'm still in Software Development. I thank my brother's protectiveness of his TS-1000 for getting me into computers.
Yes, that TS-1000 keyboard was fascinating to me too. The commands in both black and red text, and the graphics characters as you say. It was a pretty terrible little machine in hindsight, but to have my own programmable computer on my desk in my room was heaven, even if it only lasted a few weeks. Then I got a C64 :) Thanks for your comment!
As hideously user-unfriendly as the Commodore conventions "only two cursor keys" and "yep, you're in quote mode and everything is weird now, deal with it" were, yeah, it's worth remembering that some contemporary machines were *even worse*.
Ah this brings back so many memories of writing basic progs on the Vic 20 and C64. I'd forgotten about that clever ruse of evaluating Boolean statements to replace using multiple "If"s. And using keyboard shortcuts for commands to squeeze in those 80 chars per line. Shift ? = PRINT 😃
That Tenliner Cave Adventure was a brilliant piece of programming. Very Impressive! Kinda makes me want to port it to another BASIC. :D Thanks for sharing the various versions of this.
Yep, the Timex Sinclair 1000 was my first computer too. I bought it at a drug store, LOL. I tried hard to be happy with it, but it didn't take long to move on to a C64. But, I ran across a mint-in-box example a few years ago and bought it! I first played Adventure, aka Colossal Cave on a VAX 11/750.
10:41 Commodore-BASIC lines can be up to 255 bytes long… if you poke them into place byte-by-byte. 16:11 For reading, the "string slicing" is equivalent to MID$(A$,pos,len) from Commodore BASIC. How much verbiage does string slicing really save for reading? Both methods have the same expressive power for reading. How much more powerful it is for writing vs. composing new versions of strings? Does Sinclair BASIC support all of the regular string functions and string arrays? 20:38 MID$() has a two-argument variation where it returns the rest of the string starting at the given position. 21:58 C64 output is meant to be displayed at 4:3, not 16:9.
Where Sinclair BASIC really came out ahead was being able to read those state integers embedded in the string. X$(1) in Sinclair BASIC vs. MID$(X$,1,1). This is what pushed me to just break them out into variables I, J, K. I didn't know about the two-argument version of MID$(), cool!
The VIC-20 was my first computer, when I was 12. It's what I first learned basic on. Later on I got the machine code monitor cartridge, and did very simple MC stuff.
I had a similar path in my introduction to computers. ZX81 was first. Followed shortly be a Commodore VIC-20. Then my first Commodore 64. Ah, I loved this early days of discovering computers.
Love this. Yes the ZX81 allowed more people to get into coding, I have quite fond memories of them, and am trying to still make use of it today :) When you couple it to a cross assembler from a PC you can do some quite good things and is interesting to try to overcome its limitations. I'd love a VIC20, only ever had C64
Thanks Robin and Jason for showing off Ozmoo a bit! If one wishes to play a game using Ozmoo, one would go to Ozmoo Online, at microheaven.com/ozmooonline/ . If one doesn't have any Z-code files (like zork1.z3 or borderzone.z5), one can collect such files at eblong.com/infocom/ or www.ifarchive.org/indexes/if-archiveXgamesXzcode.html
It was interesting to learn more about the ZX81 (I've never seen one running before), and enjoyed the code analysis. Definitely a different coding style than in use today, but necessary at the time with the memory and language constraints.
Sinclair BASIC had some nice features. I always thought the concise "a TO b" string slicing was vastly superior to Mid$, Left$, Right$ of Microsoft type BASICs.
And here I thought I was being clever using bitwise operators to reduce the player's inventory and room contents to a single variable each. I didn't even have a reason to, given that I was doing this on a 486 and was in no danger of running out of memory.
The reason it's so slow to show the code on the ZX81 is because it's only got 1K so it slowly expands the display just-in-time to save memory. If you have extra memory, it displays the code as quickly as the Commodore. Luxury, etc! 🤭
I once was asked to translate a game on the Spectrum to run on the C64. It was a nightmare because Spectrum BASIC allowed to do things that Commodore BASIC didn't - for example drop a NEXT in a FOR Loop. I managed the job but I swore never again
There are probably some easy-ish hacks that would have made that job a lot easier, to simulate the Spectrum features, but it wasn't easy finding that information back then.
ZX81 kit, my first machine too. I was like 14 or 15 and spent many nights sitting in front of it. Ah memories. I eventually got the 16K ram expansion. Hated that it connected to tinned contacts on the edge connector rather than gold plated. You had to type on the membrane keyboard so very gently. Any movement between the computer and the ram pack threatened a crash due to intermittent contact.
Huh. C-128 BASIC 7.0 allows you to assign to MID$; I hadn't realized that wasn't a feature of 2.0. Guess it never occurred to me to try it on my VIC. :)
Fun was a machine the ZX81. I had a Micro-Ace which was based on the ZX80. The thing that I found most annoying about it was that it didn't have the screen refresh that the ZX81 had. Every character that you typed would blank the screen before displaying it. It was especially annoying as the monitor that I used would buzz for each keypress.
I believe that's the same as the "FAST" mode of the ZX81 and Timex/Sinclair 1000. I tried using that to speed up cursor movements, but the screen blanking caused extreme havoc with my video capture device, so that didn't last long.
I thought I had to be one of the few who went from the Timex Sinclair to the VIC-20 back in the day. I was astonished with how much more user friendly the VIC was in terms of developing games. I played around there until the Apple IIC days came along. What I would like to know, but don't hear much about in your videos, is what you could do messing around with Scratch.
Oof... I tried to port an old game from Amiga ABasic to AMOS, hoping to get it to run faster. The original game stored most game state and data in floating point values, not just strings, to cram even more data into less space. Alas, I found out too late that AMOS has massive bugs in its double-precision math library, so my port works fine in the interpreter but totally crashes once compiled. One of these days I might convert everything to strings, though I still haven't figured out all the crazy ways the variables are encoded.
I did actually do this but I couldn't get it to work, sadly. My MZ has a line length limit of 78 characters in BASIC which made it difficult to fit everything onto one line. I had to split some of the maths stuff onto different lines (I don't know if that would cause a problem). Also it doesn't have AND or OR but instead uses the * symbol for AND and + symbol for OR. Here's the listing: 1 I=1:J=0:K=0:X$="CANNOT DOYOU WALK OPENED CLOSED A SWORD A KEY NOTHI" 2 X$=X$+"NG A CHEST A DRAGON A CORPSE ":O$="OPEN CHEST":S$="GET SWORD" 3 L$="LOOK ":PRINT"YOU ARE IN A ";MID$("CAVEPIT HALLLAKE",I*4-3,4):INPUT U$ 4 M=2*(U$="NORTH")*(I2)-(I=2*(U$="WEST")) 5 M=M+(I=3*(U$="EAST")):A=-(3+J-2*(K=2))*(I=2*(U$=L$+"CHEST"))-(11-(K=2)) 6 A=A*(I=3*(U$="KILL DRAGON"))-(M0):A=A-(5+I)*(U$+" "=L$)-(6-K) 7 A=A*(U$="INVENTORY")-(6+(K=0))*(I=4*(U$=L$+"CORPSE")):B=100*I+10*J+K 8 A=A-10*(B=400*(U$="GET KEY"))-2*(B=201*(U$=O$))-10*(B=211*(U$=S$)) 9 I=I+M:J=J-(A=2):K=K-(A=10) 10 PRINT MID$(X$+"TAKEN YOU DIED YOU WON. ",A*9+1,9):IF A
You know there is a near mint Vic 20 listed on facebook market place in Killen, Alabama for $75, you have to search commodore to find it, but it has the original packaging, cords and cables, psu, box and manual! The poor guy has had it listed for quite a while, he says it works, but I have no interest in vintage computers, just thought maybe someone might want to know!
Very clever! It seems that a few commands in Sinclair basic are a bit more powerful than the VIC basic. I would probably go insane trying to key on a Sinclair program after being used to the Commodore BASIC ease of editing for 38 years!
Mainly because the BASIC in the VIC-20 was an almost direct port of Microsoft BASIC, whereas Sinclair BASIC was developed specifically for the target machine.
If the Zeddy still works then they never plugged it in wrong. :) There's no circuit protection on those ports either. In practice people would leave the tape leads plugged in at all times so they'd never make that mistake. Also one interesting quirk on the ZX81 is that saves also include variables so technically he could have stuffed the string values in ram outside of the 10 lines of code and made it much more complex. :)
I bought a cheap and nasty laptop a couple months ago with same jack for power and headphones. (I assume it has some kind of protection, but haven't tested.)
I believe you could plug the power cable into the mic or ear port without destroying the ZX81 because sound is AC and they probably had capacitors on those ports.
Maybe you should have used the data statement for the C= port. Instead of slicing a string you can read through your data lines representing room and items. But the Sinclair didn't had a data statement, so they had to use a super long string instead.
Give it a try! I accomplished my goal, which was porting it to the C= in 10 lines like the original. I'm not sure if DATA statements would help improve on that.
@@8_Bit I have rethought some of my ideas. On a normal adventure your have datastructures for rooms, items and mayby NPCs. But here the main structure seems to be around the actions. And you are true, maybe I should try it first before commenting how it cold be made better.
It seems that the OPENED state of the chest is never realized because it's all addition from a 0 based array. LET A=(3+VAL X$(2) + 2*(X$(3)="2"))*(X$(1)+U$="2LOOK CHEST")
Errata fix: One line change: REM I'm not sure if the Timex Sinclaire can handle this line... but: REM SWORD, CLOSED, OPEN 5 LET A=( (4*(X$(2)="1")*(X$(3)="1"))+(3*(X$(2)="0"))+ (2*(X$(2)="1")*(X$(3)>"1")) ) * (X$(1)+U$="2LOOK CHEST") +(11+(X$(3)="2"))*(X$(1)+U$="3KILL DRAGON") + (M0) Will also result in 'OPENED' ,'CLOSED' and 'A SWORD' for the input 'LOOK CHEST'. Also Robin, your VIC20 code also has the same problem of not selecting OPEN.
there is a modified rom with a direct key input, and one for the spectrum too, but the keyboard is so bad in both cases there is no point, because of the keyboard shortcomings its easier and quicker to learn and then type in basic using the sinclair shortcuts. or better still write you programs on a +2 or +3 using direct key input.
I am trying to type this into Frodo C64 emulator on my Galaxy S2 tablet. But every time I press return at the end of line 2, I get a 'syntax error' message and the first two lines disappear! If I then type LIST, they are no longer in memory. Anyone any ideas?
That's pretty weird! If you're on Twitter, can you tweet me a screenshot? I'm here: twitter.com/8BitShowAndTell You can also download the program, already typed in, from this page: psw.ca/robin/?p=301
Nice little game/port! I used this as a test case for my cross compiler ( github.com/EgonOlsen71/basicv2 ), because it does some things that "normal" BASIC doesn't do in this intensity...and lo and behold, the compiler had a problem with concatened strings in logic expressions followed by some string operation without a new variable assignment in between (it didn't reset a buffer in that case). I've fixed this, here's a compiled version for the expanded VIC20 in case somebody is interested: jpct.de/download/++10_line_adv.prg
I was wondering, what's the switch on the lower left side of the VIC-20? (ROM/memory switch?) Seem like the ZIL engine in Mini-Zork is sort of an early/simple version "AI". On the ZX-81 I can almost feel the silent key presses as I remember typing it myself back in the day... very frustrating. lol
The logical line limit for the Vic 20 is 88 (4 lines). I suppose you are sticking to 80 to comply with the 10-liner BASIC competition int the PUR80 category. Aren't you?
@@vwestlife I had not considered that point of view. I will have to think through this more. I'm a huge fan of your channel, by the way. Thanks for watching.
There are some notable differences between the U.S. and UK versions of the ZX81, so to save time in my "Those tiny '80s computers" video in which I compared them, I called the U.S. version the "Zee X 81" and the UK version the "Zed X 81".
I'd heard of SNOBOL, but didn't know anything about it, so I read the Wikipedia article just now. Those early languages are very interesting - such different approaches!
you had to give away the royal jelly to the bear to get the hint to get rid of the bear (which wasn't fair)after the bear was gone you would get the magic mirror and when you put it on the persian rug, it gave you the hint which was too late by that point. all you had to do was SCReam BEAr and it would get startled and fall...if you go to play the game again, do that instead of giving it the jelly
Correct. In GW-BASIC in particular, you could replace a portion of a string with another string by using MID$ on the left side of the equals sign. eg: 10 a$="abcdefg" 20 b$="34" 30 mid$(a$,3,2)=b$ 40 print a$ run ab34efg That last line is what the program would print out when run.
The Vic20 was released in June 1980? No way. Though it was released in Japan around 12/97, I had one of the first Vic20s as of April '80, and I still have it. It went with me through my Jr and Senior years of High School and my first high paying job as a Games Programmer and Software Engineer at First Star Software.
I said it was announced in June 1980, according to some reports; I didn't mention when it was released. Thanks for your input. Very cool that you worked at First Star Software; what games did you work on there?
Looks like your memories have a off-by-one error. This April 1981 issue of Compute has the "first look" at the VIC-20: archive.org/details/1981-04-compute-magazine/page/n27 Thanks to my guest Jason Compton for the research.
Even better, we've got a September 30 1980 press release announcing the VIC, saying it's going on sale in October 1980 in Japan and launching in January 1981 in the US. archive.org/details/19800930CommodoreAnnouncesTheVIC20
With these BASIC programs, the program is also the source code, as it's an interpreted language. If you load the program into a compatible computer or emulator, then the LIST command will show the code. I believe I linked to everything here: psw.ca/robin/?p=301
*Throws rocks* Anyways, the Sinclair ZX80/81 is very much like the Apple I with Integer BASIC in both function and design. To keep costs down, things like the RAM, Keyboard and I/O paid a price, but it also gave the machine a lot of room to expand and hack on. And think about it - An Apple I at the time was around $1000 and all you got was a mother board loaded with chips, the case, keyboard, and everything else you had to add yourself. The Sinclair ZX80/81 and Timex 1000 were less than $100!
My first computer whas a Zx Spectrum. I understand what you are doing in translate the zx81 program in the vic20 basic. But that is not the good way to use, certainly not, that is the bad way! Here is the good way to do it: 1) in a normal text editor, write the basic program to be translate 2) convert it in a neutral pseudo language totally independant of any computer / language, to get the logic of the program/code. I personnaly use pseudo code very close of pascal for is clarity. 3) rename all variables and constants in something good and intelligent: a=5 (bad practice), ObjectInPocket=5 (clear to read and understand, good practice). Same for the program: don't use goto, use subroutines with gosub. Comment your code a lot!. 4) don't mix data and code. Put ALL DATAS AT THE END OF THE PROGRAM CODE! Put all messages/strings in Name_xx$ variables. That does not use more memory space but the program is more clear to read. 5) for console game (text game), the memory and speed is not critical, other else FOR BIG TEXT GAME AND LOW SIZE OF MEMORY, do it in assembler (a good training and exercices) . With this method you can translate and optimize any kind of basic programs. You can in absolute, translate any disassembled game from NES, Apple2,Amstrad or Spectrum in a for exemple in a 68000 machine code (not emulated but really rewrite it in real machine code) but it need A LOT of more work to do and all the documentation of both computers to convert every specific code (bios calls) from one computer to another. That is the good way and good practice to do it. And the intermediate work (the logic of the program, the pseudo code (the algorythm)) can be translated in any others language or computers.
You must have missed the part where I stated my goal was to port this 10-line ZX81 program to a 10-line VIC-20 program. That would be impossible if I followed your "good way".
@@8_Bit in basic 10 lines is 10 lines but if the code is or stay unreadible for beginner human mind, it is useless! You practise assembly and then YOU MUST KNOW that byte is always the same size in basic or machine code. For the same BASIC CODE, if you write Apple=5; Blue=9; print Blue; in memory it will take the same size memory than; Apple=5b Blue=9; Print Blue; The comment will take memory only in source code (basic list), not in the binary code (machine code). In the first case, the listing is more difficult to read and cannot be commented. The second case, more clarity and readeable. The most important in coding is optimising and efficiency. If it is to make the most bad code and bad practise, it is just useless and a lost of time. For translating a code from a computer to another computer, the most important is the result of the working program, not the "size" or "the number of lines code" because that is just stupid and useless. If you cannot do better on something, don't bother with it, it is a lost of time for doing something more interesting. If you really want a challenge, translate the BASIC code in assembly with an assembler or with pokes (a loop of reading basic datas/pokes value) that execute this machone code. This will be more interesting to do.