Malban

Thanks for you interest in the subject. Sadly the owner of that particular Vectrex is not longer amongst us. RIP Olli!

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