Malban

see: https://vectorgaming.proboards.com/thread/2609/tried-6309 and the followup: https://itwww.hs-pforzheim.de/daten/mitarbeiter/johannsen/vectrex_lab/projects/mc_6309/mc_6309.htm

You can do some historic research by looking at old posts in rec.games.vectrex. Google has them about 30 years back. E.g. a sales post from 1994: (https://groups.google.com/g/rec.games.vectrex/c/FaJxXFKAu7E/m/wbx7Ub_sPmIJ) It's more work than to "just" look at some guide - but might give you some diversity... and perhaps a continuation of different prices thru the years, instead of 20 years ago and now. Just a thought...

Of course Richard - your are right. VecMulti works - I tested it!

No sorry, you will need some device that can handle 64kB roms, like VecFever or PiTrex or VeXtreme.

Hi! For those interested. Telengard, the old "DnD" like was ported to Vectrex. All "C" (and some asm) sources are freely availble. The binaries in different versions also (see readme). Head over to github: https://github.com/malbanGit/Telengard Cheers Malban

I know you are using cmoc instead of gcc. But I don't know if you know about Vide. (http://vide.malban.de/) Even if you don't use Vide, the blog, the documentation (help and other docs provided with it) and the links I have collected provide much information about "everything vectrex". If you have not looked at those yet - I'd recomend it. (also many example "C" code) Just a thought... Also Roger Boesch has developed a "beginners" IDE for CMOC coding for the Vectrex, check out his Video: https://www.youtube.com/watch?v=I3f8qO8AU_k Cheers Malban

The functions look ok - though I didn't test them. It might just be the printStr() functions of the vectrex BIOS. For them to display correct results you need strings with AT LEAST THREE characters. Try adding an additional function, which puts in leading spaces (or trailing) so the "numbers" are at least 3 characters long.

http://vide.malban.de/sales

Not to speak ill of the "dead" - only ParaJVE and the original Vecx do not display Clean Sweep Ok. DVE, Vectrexy, Vide, Mess All make pretty good attempts to display CleanSweep right!

Looks awsome! You know you'll be drowned in requests now ?... Malban

Followup on my VIA examinations: http://vide.malban.de/1st-of-june-faulty-via-vs-inc That also includes a test program whether your Vectrex might contain a "strange" VIA.

It might be interesting to you guys, during some beta tests for my new game "vectorblade" we had similar troubles on one specific vectrex. If you care to read about it, please look at the Thread: http://vide.malban.de/forums/topic/peer-testing-notes-findings-suggestion-etc (starting from topic 5) Our current conclusion is, that in very few Vectrex the VIA (6522) can not hold a stable (enough) voltage level on the PB6 pin, if that happens "wild" bankswitching can occur, which usually crashes the machine. We were able to remedy a "faulty" vectrex by inserting a new VIA (which are still availble and not too expensive). Also on all (to me) known Vectrex, the VIA chip is socketed. Regards Malban

Well. More or less as I thought. Please read (perhaps again?) my documentation at: http://vide.malban.de/ under the help section, especially the "RAM" thingy (accessed thru the menu). Line_test equ 2 Places the "Variable" Line_test into the ROM section - actually on the letter "G" (memory address 2) - it should be placed somewhere above $c880 (RAM). The only way to make that work in Vide, is when you enable "write" to ROM. (not sure - perhaps ParaJVE has a switch to allow that too) (Which I implemented for different reasons - and should under any normal circumstances be switched off, additionally - the usual Vide distribution (unless I have forgotten it), sets an automatic breakpoint if you try to write to ROM, didn't you get some kind of warning - jump to debugger at some point?). Originaly the EQU (pseudo opcode) statement was ment to define CONSTANTS not labels and not "variables". The usage to define constant labels like the BIOS locations is simply done because the code of the ROM as source is not available at that point. And the assembler interprets every "number" (even constants, or labels or names) as addresses. Labels should best be defined in the code/ram section of your program. To be utterly clear - Line_test in your context is NOT a variable (in a assembler there are no "variables" - there are always only addresses with additional "meaning") in that sense, but a constant with the value of "2". If you write lda #Line_test Than register A will have "2" as a content. If you write lda Line_test register A will have "G" ($41) as content, because Line_test points to memory address 2, which reads "g GCE"... ( the "G"). Regards Malban

I typed in your code (would have been nicer with a copy and paste!). And it works both in Vide and ParaJVE alike. But you do not provide enough information! The code cannot be fully seen, dunno where/how you defined "Line_test". Line_test should be in RAM (which I assumed), if you put it into ROM, and enabled Vide to write to ROM, than that would explain the difference. Also - I don't see where you initialize the variable - I guess the answer to that question might lead to the answer of your [edit] question. Also also, I think the proboard forum would be a better place to discuss vectrex coding. Regards

Either you are lying to us - or your camera needs to bet set to a correct date :-)

VecFever Firmware update to 1.15. Sort of an early XMas present from Thomas. This time it features the addition of a static binary compile of Asteroids. Yes, now the ORIGINAL Asteroids on vectrex! (also FAQ update to v1.7, STL files to make a vectrex stand (sideways - thx Kiwi!)). All viewable / downloadable at: http://vide.malban.de/vecfever

For people who already own a VecFever and looking for the current firmware to download - I made a preliminary page. http://vide.malban.de/vecfever Cheers Malban

Hi, testing your 'Vectrex' with a very sophisticated new homebrew us not really a great idea. Programs from Thomas push the ordinary Vectrex to the limit - there HAVE to be difference when you swap parts like that... But I further guess that not the digital part is slightly off, but only some analog parts. Perhaps it is just the fact, that you use another monitor than the original vectrex CRT Vector monitor. E.g. your start screen - the Vectrex String is off center - that is the typical display of an a) 100% digital correct emulator or b) the display of a "faster reacting" vector monitor you might look at arcade jasons tryouts connecting the vectrex to an arcade monitor - looks similar ... All original vectrex games (except cleansweep) work fine but very optimized games look screwed ... E.g. Also look at http://vide.malban.de/8th-of-november-19-monitore to have a real live test - try to get an original vectrex monitor and connect that one to your board ...

Would you care to elaborate on the "Internet HS uploading"? Edit... Found it on your website :-)!

Hi, Im quite certain that above "joystick" uses for one joystick the buttons of port 1 and for the other the joystick inputs (as digital inputs) of port 1. The creator of above "joystick" can be reached via a greek forum (english should work though): http://www.iamretro.gr/forum/index.php?threads/%CE%9F-%CE%BA%CE%B1%CE%B9%CE%BD%CE%BF%CF%8D%CF%81%CE%B3%CE%B9%CE%BF%CF%82-%CE%BC%CE%BF%CF%85-diy-robot-arena-arcade-controller.7844/ (But he is also on facebook). The other option is to use to analog sticks with both joyports like: https://www.ebay.de/itm/222794918982?ul_noapp=true Perhaps the seller reveals his plans with you - you might ask. Malban Also of interest perhaps: http://www.iamretro.gr/forum/index.php?threads/vectrex-gamepad-schematic-by-madtronix.7833/

Ha! Thomas you beat me with that! Vide 1.20 does not like your ROM - Vide has a bug! Upcoming Vide 2.0 will play your game correctly though! Nice game BTW! Malban

A good place to start might be: https://www.vectrexworld.com/ He doesn't have the "newest" - but all of the classic (homebrews) and reviews of those as well... Malban

You might be interested in another forum, I don't know if you are aware of: http://vectorgaming.proboards.com/board/20/vectrex There is quite a lot of information available if you use the "search" function... Many vectrex guys hanging out there (programers, gamers, users alike :-) ). Malban

Hi, I am sorry if I sounded rude in my last post. It is probably because I was. I apologize. Nonetheless, my opinion more or less holds. BASIC - ASSEMBLER I assume you know at least a little bit about programming, otherwise I would find it very ambitious to start your programming career doing vectrex stuff (you are nonetheless welcome to do so). But if you are just starting out programming - I would nowadays not recommend BASIC. And certainly (sorry Bob) not the BASIC of Vectrex 32. I AM sort of an IT professional, and the setup to get Vectrex32 running is not as easy as it may sound, and the error messages I encountered (using Verison 1.0) were not always straight forward. So I conclude that in some form or another you DO have some experience programming. To write "good" BASIC programs you need a basic understanding of programing, how computers work what a variable is, what a loop is, what conditionals are and so on. If you know that and can work with that you can also write (IMHO) in a couple (2?!) hours a first basic 6809 assembler program making use of the BIOS. You have to learn some "names", some BIOS routines and if you don't know the difference between hex, binary and decimal than that too. (The finer points of assembler certainly take longer, I admit, but the finer points of BASIC also, I know beginners are most of the time struggling with a BASIC "DIM" statement, you will be struggling in assembler with the difference of direct, immediate, indirect and indexed adressing, YES) Yes you have to read, yes you have to experiment and yes you must have the "courage" to do so. But let me for some minutes do a MINI example. Assuming you have found on the internet a basic assembler gameloop of a vectrex program (or just used vide). Following is a "complete" game loop for vectrex. This is a working vectrex program drawing a blank screen at 50Hz. ; load vectrex bios routine definitions INCLUDE "VECTREX.I" ; vectrex function includes BSS ORG $c880 ; start of our ram space ; The cartridge ROM starts at address 0 CODE ORG 0 DB "g GCE 1998", $80 ; 'g' is copyright sign DW music1 ; music from the rom DB $F8, $50, $20, -$80 ; hight, width, rel y, rel x (from 0,0) DB "NEW PROG", $80 ; some game information, ending with $80 DB 0 ; end of game header ;*************************************************************************** ; CODE SECTION ;*************************************************************************** main: JSR Wait_Recal ; Vectrex BIOS recalibration ; your code goes here ; up to here BRA main ; and repeat forever The only two instructions that are in it are "JSR" and "BRA" which can be translated directly to BASIC as "CALL" and "GOTO". Names you have to learn in every programming language. The instructions in assembler are not called "keywords" but rather mnemonics, but basically this is the same. Following are the first few lines of Lunar Lander, which comes with the Vectrex32: ' lunar if version() < 100 then print "You need a newer version of the SmartCart software to run this game" stop endif call IntensitySprite(72) textSize = {40, 5} call TextSizeSprite(textSize) instructions = {{-50, 90, "INSTRUCTIONS"}, _ {-80, 70, "JOYSTK IS THRUST"}, _ {-80, 50, "BTNS 1&2 ROTATE"}, _ {-80, 30, "BTN 4 EXITS"}, _ {-80, 1, "PRESS BTN 1 TO START"}} call TextListSprite(instructions) ' Wait for button 1 or button 4 controls = WaitForFrame(JoystickNone, Controller1, JoystickNone) while controls[1, 3] = 0 and controls[1, 6] = 0 controls = WaitForFrame(JoystickNone, Controller1, JoystickNone) endwhile ' If button 4 was pressed, exit if controls[1, 6] then stop endif call ClearScreen() The vectrex stuff in there you HAVE to learn, or do you know what "IntensitySprite", "WaitForFrame" or any other of the subroutines do? That is stuff that you equally have to learn in assembler there never anywhere is a way around that. I will translate the above to assembler, so you can see the phenomenal differences. ; load vectrex bios routine definitions INCLUDE "VECTREX.I" ; vectrex function includes BSS ORG $c880 ; start of our ram space ; The cartridge ROM starts at address 0 CODE ORG 0 DB "g GCE 1998", $80 ; 'g' is copyright sign DW music1 ; music from the rom DB $F8, $50, $20, -$80 ; hight, width, rel y, rel x (from 0,0) DB "NEW PROG", $80 ; some game information, ending with $80 DB 0 ; end of game header ;*************************************************************************** ; CODE SECTION ;*************************************************************************** ;if version() < 100 then jsr version cmpa #100 blt demoExit jsr Read_Btns main: JSR Wait_Recal ;call IntensitySprite(72) lda #72 jsr Intensity_a ;textSize = {40, 5} lda #40 sta Vec_Text_Width lda #-5 sta Vec_Text_Height ;call TextListSprite(instructions) ldu #instructions jsr Print_List ;if controls[1, 6] then ; stop ;endif jsr Read_Btns cmpa #8 beq demoExit BRA main ; and repeat forever demoExit bra demoExit version: lda #100 rts ;instructions = {{-50, 90, "INSTRUCTIONS"}, _ ; {-80, 70, "JOYSTK IS THRUST"}, _ ; {-80, 50, "BTNS 1&2 ROTATE"}, _ ; {-80, 30, "BTN 4 EXITS"}, _ ; {-80, 1, "PRESS BTN 1 TO START"}} instructions db 90, -50, "INSTRUCTIONS", $80 db 70, -80, "JOYSTK IS THRUST", $80 db 50, -80, "BTNS 1&2 ROTATE", $80 db 30, -80, "BTN 4 EXITS", $80 db 1, -80, "PRESS BTN 1 TO START", $80 db 0 All I am saying - do not mystify assembler. If in BASIC you have to do a if controls[1, 6] then stop endif That is similar (if not more so) difficult to understand or learn to: jsr Read_Btns cmpa #8 beq demoExit If you haven't the instructions handy you will not know what to write. In fact I find the concept that "controls[1, 6]" is button 4 of port one more confusing than a "cmpa #8" (having the background that 8 represents the 4th bit of a binary number which in turn represents the state of the fourth button). -- NEEDING A VECTREX I get that is much easier using only a computer and not having a vectrex connected. You wouldn't believe how MUCH I understand that. Being the author of not one, not even two - but three different vectrex emulators. The last being vide, which is a (get that) "vectrex integrated development environment". Trust me, if you are seriously considering programming vectrex you NEED a vectrex - (once in a while). If you want to develop vectrex programs and do so (most of the time) without a vectrex "FORGET VECTREX32" or be really good at programming without trial and error and doing everything right at once. I know I am bad at that. I think <theoretically> Bob could have made it possible to plug the vectrex32 only into the PC and have the programs loaded and executed on a "dummy" ("empty" vectrex) - that way you would at least have been able to determine if any syntax errors happened while reading the program. Also using the debugging capabilities you would have been able to single step thru the prograam (minus input from vectrex). But I also seem to remember that in the current state the vectrex32 NEEDS vectrex as a power supply, so there is NO standalone possible. VIDE I know you asked about Vectrex32 support of Vide (other forum), so, while I am writing a little book here anyway, I might respond to that. I know I give of the expression that I don't like vectrex32. That is NOT true. I like the device very much! I have it and I did spend some time with it, and probably will spend more with it. Like I said in my last post - there could have been more, but that is probably always the way. Although, the "target"-group of vectrex32 are "Beginners", the usage of the device is not really easy. A quote from the authors quick description on how to work: - Plug the SmartCart into the Vectrex and turn it on. - Plug the SmartCart via USB into your PC. - Bring up a terminal window on your PC to talk to the SmartCart. - Bring up your favorite text editor. Write some BASIC and save it to the SmartCart's USB drive. - In the terminal window, load and run your program. - Is there a fatal error in your program? BASIC will print out a message in your terminal window telling you what the error is and what line it was on. - Is there a logic error in your program? Hit Ctrl+C. Print out variables, set breakpoints, and continue running. - Are the shapes not right on the screen? Hit Ctrl+C. Change the values in the arrays that define your vectors. You'll see the changes reflected on the Vectrex screen immediately. - When you've figured out the fix for the problem, change the BASIC in your text editor, save the changes to the SmartCart's USB drive again, and reload the program from the terminal window. Run it again and see the results. How many people (that are not computer professionals) know how to handle a "terminal" or even know what that is? It is NOT the command line window, which itself is not used much anymore. A terminal window is the "frontend" of a serial connection to a device (or pc) that is fed over a serial connection with (usually) ascii characters. The terminal accepts and transmits (usally) ascii data bi directional - the history reaches back to mainframe computers that were only accessable over "terminals". I am not even sure if the latest window even has a terminal "program" included - I rather doubt it. You probably have to find a terminal "emulator" on the net and install it. Than you have to configure it to (if I remember right) 9600 baud and "experimentally" find the right serial port, ouch, I forgot, todays PCs do not have serial ports anymore. You have to find what serial port the usb port of your computer "emulates" - and use that! So developing for vectrex32. Good thing is - you can use any editor you like. Bad thing is, you must use an editor. "professional programmers" have such things lying around, if you are not, that you will probably have to use "notepad" (on windows) or find one that suits you. You edit your BASIC program using the editor. When finished you must save the program to the vectrex32 USB drive. When plugged in vectrex32 represents itself as a USB drive with (if I remember right) a few hundred (480?) kiloByte. You must save it to that drive (but for savety you might also save it someplace else - you do not want to clutter your vectrex32 device, remember 480 kiloByte). When finished you have to switch to your terminal program, connect to the device (which hopefully is configured), depending on the state of the vectrex 32 you probably have to press/type: CRTL/C STOP LOAD “currentFile“ RUN If an error occurred - you go back to your editor and start again. Overall there is quite a switch between usb drive, your editor the terminal window and the vectrex, more so if you debug or encounter errors. While you can do a great deal of stuff, it is <very> cumbersome. Here comes VIDE into play. The "menial" tasks it helps you with. You once set up which usb drive to use, you once setup the serial connection. If done so, you stay in Vide. You can edit, save, load and debug (using a terminal IN vide) all in one program. Also the editor has some rudimentary syntax highlighting when editing your BASIC. But Vide does NOT emulate BASIC, it only allows you to more easily use the device. @ToyguyVT: ... In fact, on further research, I'd guess that it isn't as you'd need the same PIC processor and RAM to run the game, since the Vectrex becomes just an I/O device. ... I sense there is a "not" missing in that sentence - your conclusion suggests that at least. And the conclusion is exactly what I meant by "People do you THINK befor you write?", but yes - I could have phrased hat more friendly... Anyway. Even if I may come across as the bad guy here - I am a huge Vectrex fan, I like programing and I also do not mind helping out, I will gladly help you if you want to step into the vectrex programming world. Regards Malban

Hi, some short notes: a) You should do the WaitRecal only once (at the beginning usually) in your update round, since it waits till the rest of your 30000 cycles have passed and than goes on. b) to reset the beam position (other than WaitRecal) you can use a different BIOS Function "Reset0Ref" c) untill you know better, after such a Reset you should do a move (what you already do - good!) d) all positioning is done from the last "location" the vector beam resides this is called relative positioning. e) within that relative positioning you do NOT tell the routines which coordinates you want to go to but rather tell in which direction (and distance) the next "point" (or endpoint of a line) lies f) so, going from 0,0: 30 "pixel" up and 127 "pixel" right draws a "diagonal" from point 0,0 to 30,127 (but still notice, this is relative movement - it just looks absolut since you started off at 0,0) if you do exactly the same move "30,127" directly after the first, you will have the "same" diagonal again, which in effect doubles the line and from the view of point 0,0 is a "60, 254" line Malban