Malban

To a small degree Thomas (VecFever) emulates Pokey chips (Atari sound chip). But the emulation is not what makes the sounds good on the VecFever. The original sound of star wars is produced by 4 × Atari POKEY, each Pokey features 4 sound channels... that means in Star Wars it is possible to play 16 different sound channels at once. Unless you use "modern" mixers and digital sound processing this can not be done by a Vectrex. There is also no "good" way to discern which of the sound channels at any given moment is producing the most audible sound. What Tomas did for nearly all his emulations... is to reproduce the sound of the arcade machines with the means of the AY 8912 - which means he "composed/rebuild" those sounds from scratch. Within the emulation he tracks the code, what sounds are played... and "emulates" the sounds by playing his own sounds. He had to make decisions on what sounds to play, what not... and what should/could be played in parallel... It is a painstaking process to do for only one arcade emulation - let alone the many emulations he did. I myself am no "sound"-guy, never was, never will be. The technique Thomas used to intercept the emulation and play his own sounds... is easy to implement - and actually is also implemented for Star Wars on the PiTrex. BUT: I myself never intended to create new sounds - or rebuild sounds on the AY to sound like arcades. For Star Wars I implemented place holders of sounds I had lying around (done by another person). There always has been huge interest in having better sounds/better emulation/better graphics with the PiTrex. Better emulation - I could do. Better graphics - I very probably could do also - I even asked Thomas for his help, and he showed me a path to take (which I was already on... but he confirmed it). Better sound - I am not willing - and probably could not do. Be it as it may... I asked the "community" repeatedly for help with the sounds... one or two people offered to help... but I never actually got any feedback later. I grew very much tired of the PiTrex... every now and then I dig it out... and think about the changes that I had planned (and started) - but the time needed to get back into the code grows from month to month... so due to other things in my life I postpone it further and further. - as a small side node... Start Wars on PiTrex also uses SBT - which Graham provided... PS In the file starswars.c - last function... the sounds are "mapped": (and you can see the few "sounds" the PiTrex actually "emulates"...) void play_sw_sound(int a) { if (usePSGSamples) return; int channel = 0; // printf("Sound: %02x\n", a); if (a == 0x1c) v_initYM(cantina, cantinaRows, 0); if (a == 0x3a) v_playSFXStart(playerShot_data, channel, 0); if (a == 0x24) v_initYM(jingle1, jingle1Rows, 0); if (a == 0x22) v_initYM(jingle2, jingle2Rows, 0); if (a == 0x26) v_playSFXStart(deathStar1_data, 1, 0); if (a == 0x27) {v_playSFXStart(deathStar1_data, 0, 0);v_playSFXStart(deathStar2_data, 1, 0);} if (a == 0x33) v_playSFXStart(shieldHit_data, 1, 0); if (a == 0x34) v_playSFXStart(enemyHit_data, 1, 0); if (a == 0x35) v_playSFXStart(deathStar2_data, 1, 0); if (a == 0x36) v_playSFXStart(fighterShot_data, 2, 0); if (a == 0x39) v_playSFXStart(longerShot_data, 2, 0); // 1b - high score // 1d - Imperial March // 20 - Towers 1 music // 21 - Towers 2 music // 22 - Trench music // 24 - Space wave 1 music // 25 - Space Wave 2 music // 26 - Explosion // 32 - R2 beeps entering Death Star /* http://www.wardclan.f9.co.uk/136021_Sound.html * see also: https://github.com/historicalsource/star-wars/blob/main/SNDPBX.MAC 00 ROM:7F61 off_7F61: fdb Reset_Vector ; Sound/speech function pointer table 01 ROM:7F63 fdb FX_loc_743C 02 ROM:7F65 fdb Mus_sub_7686 03 ROM:7F67 fdb Spch_loc_7BAB 04 ROM:7F69 fdb Spch_loc_7C0D 05 ROM:7F6B fdb Spch_loc_7BBA 06 ROM:7F6D fdb Spch_loc_7BB3 07 ROM:7F6F fdb Spch_loc_7C14 08 ROM:7F71 fdb Spch_loc_7BC2 09 ROM:7F73 fdb Spch_loc_7BDB 0a ROM:7F75 fdb Spch_loc_7C1B 0b ROM:7F77 fdb Spch_loc_7B7E 0c ROM:7F79 fdb Spch_loc_7BFF 0d ROM:7F7B fdb Spch_loc_7BE3 0e ROM:7F7D fdb Spch_loc_7BD4 0f ROM:7F7F fdb Spch_loc_7B6D 10 ROM:7F81 fdb Spch_sub_7B65 ; $10 Red five standing by 11 ROM:7F83 fdb Spch_loc_7BA3 ; Remember 12 ROM:7F85 fdb Spch_loc_7BF1 ; I can't shake him 13 ROM:7F87 fdb Spch_loc_7C06 ; Look at the size of that thing 14 ROM:7F89 fdb sub_7C40 ; Stay in attack formation 15 ROM:7F8B fdb Spch_loc_7BCB 16 ROM:7F8D fdb Spch_loc_7B90 ; Force is strong in this one 17 ROM:7F8F fdb Spch_loc_7B76 ; Red five I'm going in 18 ROM:7F91 fdb Spch_loc_7BF8 ; $18 Luke trust me 19 ROM:7F93 fdb Spch_loc_7B88 ; Use the force Luke 1a ROM:7F95 fdb Spch_loc_7B9A ; Yahoo you're all clear kid 1b ROM:7F97 fdb Mus_sub_753C ; High score 1c ROM:7F99 fdb Mus_sub_755D ; High score Cantina 1d ROM:7F9B fdb Mus_sub_7665 ; Imperial march 1e ROM:7F9D fdb Mus_sub_7644 ; Enter Death Star 1f ROM:7F9F fdb Mus_sub_757E ; Death Star destroyed 20 ROM:7FA1 fdb Mus_sub_7602 ; $20 Towers 1 21 ROM:7FA3 fdb Mus_sub_759F ; Towers 2 22 ROM:7FA5 fdb Mus_sub_75C0 ; Trench 23 ROM:7FA7 fdb Mus_sub_751B ; Exhaust port hit torpedo 24 ROM:7FA9 fdb Mus_sub_75E1 ; Space wave 1 25 ROM:7FAB fdb Mus_sub_7623 ; Space wave 2 26 ROM:7FAD fdb FX_loc_7401 ; Explosion 27 ROM:7FAF fdb FX_loc_73F5 ; Death Star explosion 28 ROM:7FB1 fdb FX_loc_740D ; $28 R2 dead 29 ROM:7FB3 fdb FX_loc_7435 ; Memory fail boop 2a ROM:7FB5 fdb FX_loc_73C5 ; Tie fighter pass 2b ROM:7FB7 fdb FX_loc_73CB ; STOP PASSBY SOUND 2c ROM:7FB9 fdb FX_loc_73D7 ; Tower pass 2d ROM:7FBB fdb FX_loc_7419 ; Laser fire ;PORTHOLE (ASSISTS PMSF2) 2e ROM:7FBD fdb FX_loc_73FB ; Tie pass 2 2f ROM:7FBF fdb FX_loc_7407 ; R2 increasing power 30 ROM:7FC1 fdb FX_loc_73B7 ; $30 R2 answer 31 ROM:7FC3 fdb FX_loc_7420 ; R2 32 ROM:7FC5 fdb FX_sub_73B0 ; R2 enter Death Star 33 ROM:7FC7 fdb FX_loc_73D1 ; Shield hit 34 ROM:7FC9 fdb FX_loc_7413 ;PLAYER SHOT ALIEN SHOTS 35 ROM:7FCB fdb FX_loc_73EF ;ALIEN SHIP EXPLODE 36 ROM:7FCD fdb FX_loc_73E3 ;TIE FIGHTER CANNON 37 ROM:7FCF fdb FX_loc_73E9 ;TIE FIGHTER CANNON END SOUND 38 ROM:7FD1 fdb FX_loc_7427 ;THRUST TO DETH STAR 39 ROM:7FD3 fdb FX_loc_73DD ;TOWER LAZARS 3a ROM:7FD5 fdb snd_Fire_Guns ;X-WING LAZARS 3b ROM:7FD7 fdb FX_loc_742E;YAY - TEST PASS */ }

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