Wrote C-65 Game "XEVIOUS" (Atari-Namco) team. Ask (me) anything non-secret C64

[RJSV]

You can ask, coding bit maps, etc. 6502 general questions, won't hurt game, that was 1986
  Good advice on LOOPs, etc.
  Medium level guidance, but try me. Didn't learn much on audio, however.

[MK14]

Like this (related) online playable version ?

https://www.retrogames.cz/play_049-NES.php?language=EN

Keys.
Z seems to fire and work if permanently held.
X seems to work, without needing to release Z, and drops bombs onto the field.
The array keys move up, down, left and right.


The following video, seems to be an original from around 1982. It rather nicely explains how to play it, and demonstrates it well. If you like retro/vintage stuff, it is probably worth watching.

[RJSV]

Uh, thanks; we meet again, well I'm not familiar with that specific version:
  We were approached to form a re-write team, creating an action-matching game stored on C-64 floppy. The big CORP. Namco took care of added copy-prevention and sales, etc.
  We had a sit-down style Arcade quality system, to beat on, while an artist went to work, making screens and sprites (simplified moving bit- mapped objects.)
   But very close look, to your picture, up top there.
   We used virtually all memory, C-64 has 64k RAM, plus alternate mapped ROM in 16k (?) chunks.
For map changes, you could flip which one was current and I (think) still get at things in other 16k blocks, without switching constantly.
  Keystrokes control, that was 'other person's job, but he would pass parameters, to graphic portions of code for display and animation. The bullets moving for example, were directly animated, using XOR, for blinking, madly, against a scrolling screen (a speed issue).
  My neighbor was Arcade machine service biz, so that was a happy coincidence, the martial arts and car race stuff so cherished today... Like 'Lost in Space' episodes.

[RJSV]

  Someone Taught Me a method:. a CODE  TOWER.

 With C-64 processor speeds, here is a helpfull Graphics handling:
You have to, example, put every pixel to '11', a Commodore specific, but it is simply 4 pixels packed into the 8, each Byte.
The 'tower' is just a bland stack of repetitive instr, often looking like this example:

  Lda #08 h
Loop_Block1
  STA. 2100, Y
  STA. 2260, Y
  STA. 2420, Y
  STA. 2580, Y.

  INY.      That's equiv to index++
  Branch back, etc. to Loop_Block

  The graphics is not all that convoluted, on the C-64,
but requires considerable 'bulk' of details.
  When doing 8 kB screen copy, that CODE-STACK above has each 'cell' something like this:

  LDA. 4100,Y
  STA. 8100, Y
  INY

[james_s]

Xevious could have been a decent game but it had such horrible "music", seems like it was 4 or 5 notes over and over and over. It could drill a hole in your head.

[MK14]

Xevious could have been a decent game but it had such horrible "music", seems like it was 4 or 5 notes over and over and over. It could drill a hole in your head.

I'm NOT trying to say you are wrong, as such. But, the OP did say:

Didn't learn much on audio, however.

So, presumably they were not involved with that part of the software (conversion).

In the playable version of the game I linked to earlier. (Which the OP, said is NOT the specific version, they were involved with). I did play with it, for a limited while. The music (if I dare say that), was ________/ Where ____, means I have run out of words to describe, how bad and repetitive it sounds.

I bet, a 3 year old, playing on a $2.99 kids toy electronic organ, at the exact time these games were written/created. Could play something, considerably better.
Unfortunately, I'm NOT joking here. (Or not much, anyway).

[RJSV]

  ALL Honesty, audio prog, was (is) miles beyond my (moral compass). Many times, we lie, innocently, but I would not try... The dude actually taught me some coding trivia, but usefully !
   
  The little bird that sings, changing the subject, seems to pipe actual 'audio' thumps, to the little motors, for wings.  So the recent toys teach a lot, of new approaches.

[Alex Eisenhut]

As a kid that was my favorite game in the arcade! It was hypnotic, I don't know why.

[RJSV]

Thank you Alex, I guess my fave is 'RYGAR'

  Briefly, I checked and est using a so-called "Code Tower" can be 2 X faster, the C-64 often has 25 at once, plus better to use Y index downward, faster checking.
  You can 'race' the actual video beam, starting it just behind it. Then, a 50 hz or 60 hz scan will eventually catch up, but has retrace delay too.
This way, avoiding flicker inducing.
  C-64 has the Beam-Retrace, bit flag.
(Hope that was correct ?)

[RJSV]

  I also wanted to layout some (typical) C-64 screen graphics handling, mostly the bit mapped and scrolling screen, of XEVIOUS.
  Well, we actually borrowed some pretty common stuff, TILES and STAMPs, where the stamps are really explained in the hardware: however a 'TILE' being a pure software structure (again common in game machines.)
  So, a TILE is a quick list, has a 2 by 2 square, listing the contents being stamps. The artist chooses the 4 desired stamps, often having a set up to 256 stamps.
 A sub-structure to the tile system, each stamp is an actual little bit-map, 4pixels wide by 8 (lines) high.
So for the copy of one stamp, you would copy 8 bytes sequentially, each byte has 2 bit pixels packed 4 to a (byte).  Usually, that code is with a speed concern, so no individual pixel is of concern. You can then imagine, a TILE structure would be a list, of so-called pointers or 'stamp' numbers. That actual hardware map is Commodore specific, but the TILE data can be anywhere convinient.
  There was also color and size varieties as TILE and 'stamp' set ups were a hybrid, pure software plus the hardware derived 'stamps'.
For movement, this code was for the background, there was movement, but only vertical 'scrolling' for 8 lines worth of (whole) screen offset... Then, it was necessary to sort-of 'jump' by 8, that accomplished as a new screen, another whole screen mapped.
That alternate screen would then be, as before, moved vertically, counting out 8 lines worth.
  Meanwhile, another new bit map screen would be built up, tile by tile,... stamp by stamp.
It's a mess, on the C-64 and used 70 percent of CPU clocks, just for XEVIOUS scrolling screen.

[MK14]

It must have been very difficult, in those days. With so little capabilities (compared to modern times), on the 6502 (relatively slow, by today's standards), packing all that functionality into only 64K of Ram (not all of which was easily accessible, as you previously mentioned).
I suppose, those were the days of the hero software creators.
I presume, it must have taken a lot of skill and patience, to do that then.
Even the powerful desktop PCs (or laptops), we nowadays would use, to perform/develop such software, did not necessarily exist (not invented and/or available, if long enough ago), or was too expensive at the time, for everyone to have one.

Even if you did have such a PC, it would have been an ancient specification one. Not necessarily having a hard disk, high resolution screen, or even a colour screen (many early computers, had only monochrome).
No windows, no mouse (I guess), no access to the internet, in those days. No forums for asking questions.
No mobile/cell phones, for asking colleagues for help. Not even that much in the way of software packages, to help the design process along, even Microsoft paint, wasn't around then.
I've probably missed other modern technological wonders, we take for granted, that you didn't have access to then.

[RJSV]

   "Stone Knives and Bear Skins...".  Doc McCoy

   "...you follow the CODE: The CODE a the DORK..."
  ...- gamer artist Greg

Yes, heady times w ZEVIOUS, heady times. We, in the moment had sacrificed, and each thinking: how much we wanted this (tormented task)!

  So, to continue, for coding a scrolling screen, pls don't imagine the 'TILE' graphics as being set down on a whole screen: rather it's a series of block moves.
Then, a row of new TILEs are put across the top.
  Now, once written the hires graphics are a simple bunch of stamps, copied onto the hardware bitmap (block of 8k screen memory). Between the preparatory block move ( down) and the new TILE lay, each new screen is complete.
  Next, a timed switch of maps takes place, substituting each new screen, while old mapped (8k) screen will be completely re-built, for next display, eight steps of scroll further down.
  Across, there were ten med size TILEs (20 stamps), for a 'whopping' 160 pixel screen width.

    "NEVER write code to move large blocks of data!"
   -- Rodney Zak's,  author of "The Z-80 Prog Manual"

[RJSV]

Oops, meant to say "there are 20 TILEs across the screen top", not ten. It helps also, to imagine each 'stamp' as in a regular text character sized box.
  For those interested in game development / production tools (MK14 et Al) I used the HESMON debug monitor, a game cartridge with ROM that could take over, for examine 6502 (6510) registers in usual bug fighting.
  But that was the limit of (my) expertise. Bought my system, thick Commodore users manual, dot mat printer, (and HESMON cart) at TOYS 'R US... Yeah, I know, pretty saavy, there.
  Ted (also Larry) was the real hero... Supplied support with MS-DOS system, for the glue that brought all together, graphics, code, disk loader; All that came Via MSDOS... saved all our butts.
  The artist had a MAC, the only real system in that office! It was shared, president, marketing, shipping, everyone used that one 1985 Apple Mac.
  Things didn't go well, always, and I don't say that to complain: My choice here is to avoid the colorfully history, for helping those wanting to write CODE, on a C-64 orig or heritage copy.  Hayward city is 30 minute drive, to former ATARI buildings, by the way. I could write, colorfully stories, "lookit those older bullet holes, in my apartment wall, there". But for that, remember that movie: 'Pulp Fiction'. (Hayward has similar past).

  Looking at first diagram, shows 4 of the bit-map 'stamps' making up one TILE. A register-indirect creates each for color. Your bit pair will specify the register, that's in one of 3 places, each a byte, in coordinated blocks, elsewhere in RAM.  So a 11 for example, tells hardware (video VID IC) to use the color RAM, to get the ultimate color.
For two other colors, the indirect points to proper nibble (register) this time in the 1k 'screen RAM'; that's where text typing is, in low res modes.
  So you've got maps all over the place, different resolutions, result is you can call 'FourColor', chosen from 16 possible color options. One subtle aspect, using the common TILE and STAMP system, the stamp provides shape, the tile assigns colors, so a full screen can include ALL shades, the restriction comes at each little local area, with four (shades) available.
  Clear as mud, plus my babbling.  Don't let that quit you:. Get the damn BOOK!

  Now, the first diagram was limited, to show a single color (actually that's a sprite, SPACE-SHIP), and second diagram shows full TILE: the green pixels are done register-indirect, to using high nibble, corresponding directly to that mapped stamp. Literally,
the full 8k is mapped down into corresponding 1k, which is calculated using quick bit shifting, but also zig-zagging along with the hi-res zig-zagging map..
WHEW, this is hard to explain, consider!
Clearasmud, clearasmud.
  Now, take a glance at the hex address, see the left side, of a TILE at 4100 h.  Notice the lower stamp; it has location 41A0 h.  That shows, right there, the 160 byte offset, A0 h being 160 decimal. To follow that, you walk down, 8 bytes(lines) then zigzag up to next stamp. Doing that across gives 160 bytes, 40 stamps by 8 bytes each. OR, 20 TILES across, remember each is a 2 by 2 organization.
  For those truly into doing some, please look around for that (thick) Commodore book / manual... It was 6 by 8 inches, with heavy binding loops.
  That maybe clear but not at first!

[RJSV]

Errors last time, realized that the offset is +320, for the C-64 HiRes, row to row (of 8line stamps). So corrected TILE diagram shows, 4100 h + 140 h that's your 320 bytes. I show, also location 4247 h and encircled that (slice of 4 pixels).
  Right now, going to show some code example, the routine for 'new' tiles operates using partial tiles, an even or odd scheme for scrolling (hardware really only thinks it's a set of stamps.)

Next_Stamp.  Gets A= the stamp no.
* and converts to point to stamp bit map (at 2k -4k)
  LDA (46),X.   X has index into tile
  INX.                 Next stamp
  STA 80h.        Low ptr
  LDA #01h.      This will be shifted three times, to 0800
   STA 81h
*
   ASL 80
   ROL 81
   ASL 80
   ROL 81
   ASL 80
   ROL 81
* this code  just mult by 8, plus 16 bit base
   RET
*
*. Ok here is the stamp copy part
*
   JSR Next_Stamp get pointer to stamp in storage
   LDY #7.   8 slices
Loop_stamp1:
   LDA (80),Y
   STA 4100,Y.    to screen
   DEY.                  next
    BR NZ Loop_stamp1
    LDA (80),Y
    STA 4100,Y.    last slice
*
   JSR.  Next_Stamp
   LDY #7
Loop_Stamp2:
   LDA (80),Y
   STA 4108,Y.  this is the 320 byte displacement
   DEY
   BR NZ Loop_Stamp2
   LDA (80),Y
   STA 4108,Y.   last slice
*
*
   OK, now please if you want to appreciate the power, of 6502 instructions, the 16 bit pointer used for retrieving a bunch of bit map slices, this above code is a nice start. Notice the bit ROTATES and SHIFTS, effortless, nearly. Well, it ALMOST makes up for other headaches right there.
  Study that multiply, and adding of 16 bit base...
Where's that, you say?  How's that?
(Didn't see a multiply)....

RJHayward Aug. 2020

[RJSV]

     "He said the MEMORY is all Zig--Zaggy...."

Oh, the horror!
      "...PAGE  ZERO !!...  Sounds like a celebrity, name..."   "... besides:  the functions don't even USE the accum."

I've heard some of that.  So some speculation, if (ever) going to be some kind of re-issue. But I'd like, if that happens, like to see some C-64 vintage magazines and, particularly interested in an 'official' SCHEMATIC.

    The C-64 'VID' chip, well, has a shadow RAM chip: I believe it is 4 bit wide, by 1k. That's a DMA optional set up, where the VID reads (color nibble of interest) directly. Programmers simply write to the separate memory IC, even Basic, and that is mapped, way way up top, maybe up near 58k 'ish.
   Anyway, that right there could be basis of some (phoney) intrique: 'Secret chip buried under C-64 volume control...'.
  But actually, it's an everything scatter-map. You have the 64kb, under there, plus the '1k color ram', on top.
The processor has that 64k limit, and registers / code is all focus, on the 64k range (16bit address).

  "...this guy doesn't cough up any corrections, for days
    if at all..."

Oh well, -- corrections and bug fixes are where you make your money )lol)

  So, for the last coding with bit shifts, here is detail:

   Say stamp number 7.
   You want 7 x 8 plus a base of 0800 h.
   A quick glance, you realize you can start with
   01 07 h and that 1 can be shifted, along with the stamp number. Otherwise, your code will simply do a pair of 8 bit adds, (ADC instr).
   Honestly, big part of code writing is getting your locations of use (in page zero).

So, 01 07h looks like  0000 0001 0000 0111 b
 Now with three shifts, effectively each is a 16 bit,

    instr:. ASL
      and.  ROL  (each on pg 0 reg)

   So, in total you've got a 16 bit shift, with the right details, such as the first instr shifts in a 0, while second, high byte, gets the CARRY proper.
 
  Any C-64 SCHEMATICs out there

[MK14]

  Any C-64 SCHEMATICs out there

Google seems to find many.
E.g. Here:

http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/c64/

http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/c64/servicemanuals/C64-C64C_Service_Manual_314001-03_(1992_Mar).pdf

http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/c64/servicemanuals/C64_Service_Manual_314001-02_(1985_Mar).pdf

[rsjsouza]

Quite interesting talk, thanks for sharing the details RJ.

Xevious was one of my favourite arcades when I was a kid back in Brasil (C64s were non-existent as they were impossible to clone by the local companies and imports were not allowed).

Funny how people used to call it "Columbia" after the Space Shuttle - no idea why, given that "Xevious" was written in the main screen.

[RJSV]

Wow, would you (mind) tell us more, I'm assuming that was circa 1982, with import control, can't wrap my thoughts around (that probable mess)?
  Oh, the crime potential, a C-64 costing $2500 US. ?
  Pls, or you may also start a cool thread, on arcade and personal electronics, then and there !!!

Enclosed, less exciting, I did explore the C-64 speed up issues, and came up w a 'BANDWIDTH' thumbnail.
(But, hey, my favorite Arcade Zevious version, my favorite was those rotating plates, out there in space)

   So, from that 'Code Tower' discussion, I felt efforts led to a 'asimtote' curve, of CPU speed doing basic block moves. Enclosed curve, that's the low (blue) curve shows the roughly 2 X speed, using 24 elements in-line rather than tight loop.
  Try just code to
     LDA blah blah,Y
     STA Scooby-Doo,Y
*
Etc just fill your code space. Then, max speed comes to about 80 kbyte per sec.
Call that a Bandwidth type G.
Came up with that using a crude est of 5 + 5 + 2= 12 micro-sec.

Faster, I coded at 4 + 4 = 8 clocks, or usec.
So that is the orange line.
That graph gives some sense, of hard upper limits, on code speed. On the XEV game, est of screen block move and new tlles came to 70 milli-sec.... way too long for a 16.7 msec raster sweep repeat time.
  Then realized, the game has also 8 steps of scroll on hardware, that giving about 130 msec.
That's where I came up with figure: 70 percent, of CPU clocks, for scrolling function.

  But brings up a video related question:
Being a flat screen, HD laptop screen, who cares about (video) RF, or Baseband, anymore.?
And does CRT raster friendly code mess up, w modern flat technology ?

But I digress, let's hear some more about South America, 1980's... Thanks for that!
- Rick-Jack

[RJSV]

Tiles, and Compression

Photo has one of the graphics screen sweeps, a moving display over the VIRTUAL and un-compressed playfield of the game. 120kb

Recall, took 40 seconds before wrap-around, and a bland patch of scenery (design) kept seamless and varied fly-over looks. 64 tiles across, you can picture using 128 max from a pallet tool. So each tile can be a small 0 thru 60 range, easy. Later conversion is for physical address, into your storage. It was only, 1000
Tile store area.
Stamps, similar, used about 60, (they get tiresome) so you could observe the sys is under-used)
So stamp buffer was also merely 1024 bytes.
  The 'world' playfield, was 64 by 64 tiles, however, each instance of Tile recreates 32 bytes on-screen.
The 64 by 64 playfield list, is 4 KB, starts to impact the C-64 game, that product loaded, and ran with no disc access.
STAMPs by clarification, are a pure software construct and tightly linked in format for copy, stamp bank to hires screen.  Before, prev post example stamp and code to make a quick pointer 16bit.

[RJSV]

  Adding depth of color, if can't speed up the
TILE/STAMP sys

If use a full 256 stamp shapes, same speed, just will use 2k. Plus, any TILE will flip horz/very. So that is 1025 possible pixel forms.
Creation system has to account for no mirrors, in the base stamps, for best.
TILEs: Suggest 16 bytes per tile, 4 each, per stamp.

Result is each stamp gets 3 colors, plus possible flips.
Biggest tile can run thru 12 colors, figure 3 per 'stamp'

The figure shows using 8 colors, 3 different ones, in each of the four stamps, or called 'cells' also.
Figured 250 Million diff pixel sahapes...but this could make some great depth of colors, or rich-ness.
C-64 has 16 colors

[RJSV]

You could do a video-like repro, a smaller screen area at maybe 12 frames per sec. Using this same Tile and stamp system.
Taking some 600 bytes, and 5 pages code, routine doing pixel copies is worth having flips, both Very and Horiz. So see following ex.:

Backward Vert:
    LDY #7
*
     LDA (80),Y.  get slice
       DEY
     STA 4000,X.  to screen
      INX. next hires screen pos
"
    LDA (80),Y
     DEY.      next
And so forth, for each of 8 slices copied

  Now, after BIT test finds flips:
You use Y temp so have to keep reload
   LDY #0
   LDA (80),Y. stamp slice
     TAY fliptable will provide H flip
     LDA FLIPTAB2,Y
     STA 4000,X. to hires screen
*
  Notice this above, gives both flips. Each variation writes to screen forward, vertically, but option to pull it out (stamp bank) 'upside down' and table translated horizontal flip is tedious.
  For example 0010 0000 becomes 0000 1000, in horizontal mirror. Bits are in pairs, so third place pixel swaps to be second place. Place that as a 08h, in line two of table...
  Obviously, some computing power is required, in pre-producing the 'video-like' display square, and don't be naive about the 16 colors, some are completely dorked! But consider, maybe 8 color shades...

[RJSV]

Sourcing Dilemma:
There are 4 billion pixel combinations, consider 4 by 8 and that's only single color. When 3 colors for choice then it's a huge num.

So it's a Source Dilemma, just one stamp (8bytes).
The stamp bit-pairs make for 'virtual' colors, future real assignment. But for now, called colorA, colorB,
colorC, before actual assignments, from tile.
  In building an artificial set, it's hard to get past 60, let alone 100 stamps, manually. C-64 has a set.
Once a stamp set gets to 150: You still have to come up with another 100 shapes, (and weed out any mirrors). On other hand, once start with all three colors the combinations multiply, rapidly using up the 256 range.

Photo shows a tile, shows a more random-like approach does not do badly.
The random and diffuse look, just as useful as a contrived shape, such as line or square.
Needing an AI system, for building the stamp and tile set. The video-like player is 8 by 8 tiles, for 10 seconds, alternating two screens, 10 hz.
That darn C-64 hires needs a big sys to feed it!

[rsjsouza]

Thanks for the details and thought process; it is not every day that one goes through the mind of a developer of that era.

Wow, would you (mind) tell us more, I'm assuming that was circa 1982, with import control, can't wrap my thoughts around (that probable mess)?
  Oh, the crime potential, a C-64 costing $2500 US. ?
  Pls, or you may also start a cool thread, on arcade and personal electronics, then and there !!!

Well... Not much to tell. Imported finished goods were forbidden for the common man and only the very few lucky ones that travelled overseas could eventually bring something - either under tremendous stress of being caught by the port authorities, having some relative "in the know" or having some extra $$$ on the side.

The market in the early 1980s was very fragmented and dominated by clones manufactured by several local companies: Microdigital (Sinclair clones, later Apple ][c and ][e clones), Microcraft (very well crafted Apple ][ and ][e clones, even created a McIntosh prototype), Prológica (Sinclair and TRS80 clones), Digitus (TRS80), and perhaps others that I don't remember. In the second half of the 1980s, large local electronics manufacturers Sharp and Gradiente started to massively dominate the market with MSX manufactured under license but, in the turn of the 1990s, import restrictions started to be slowly lifted and smuggled PC parts pretty much consolidated the market.

History tells that the McIntosh clone done by Microcraft was its demise, since the Brazilian government forced the company to shut down after pressure from the US. This was triggered by Apple, which for years was trying to prove to the US government these clones were copying Apple's own ROMs - without a smoking gun, they draw blanks. When the McIntosh came, Apple inserted one innocuous "Easter Egg" in the code, to which the prototype also had and therefore proved they used their code.

The Arcade market was not very different; there were probably many bootleg ROM clones, but these were harder to track as they had worldwide distribution. Of course, for the common kid/teen, purchasing one of these was completely out of reach. The pinball machines were different: all of them were conceptualized and created locally, with local themes, decorations, etc.

Oh well... There are many other stories but I suspect I derailed this long enough. Back to normal programming.

[RJSV]

Thank you. First tho, gotta pay the rent...

C-64 TV (compression related)

   Photo shows the so-called 4 line DEMI-STAMP, where concept keeps an even smaller TILE and STAMP division.
  With a (hypothetical) larger /faster system 'crunch' down a sample video, perhaps a stamp (4 by is too big for getting multiple shape matches.
The video 'sourcing' software would be looking for matches, or near-matches, in order to have repeat use (of basic pixel shapes).
Also, along this subject line, it was realized: most natural videos may not contain much in the way of 'mirror' repeats. It is expected, that most cases, any repeated (stamps) having mirror shapes (vertical or horizontal) may be only a mere handful (compared with a main set of 256).

So, imagine a 'crunch' software run producing two sets of Demi-Stamps, 256 in each set. Thus a tile, keeping near to discussed formats would simply contain pointers to 8 Demi-Stamps. Previously a more conventional tile would list 4 full stamps. The pointer can be stored, for direct speed-up.

The photo, upper 4 lines shows a Demi-stamp wherepixels are further lumped, an example 2 X 2 pixel result.(green boxy areas)
This is simply to illustrate, a final arrival, where a Demi-stamp set can fully encompass all possible (256) shapes, that's 4 colors, 2 by 2 pixels.
  Now going back to 4 X 4 a fully expressed set of pixels in a demi-stamp has 4 billion combinations (16 pixels by 2 bits each).

Seems like actual C-64 color performance is not as pessimistic as the numbers suggested.
It's the graphics sourcing that's going to be needed, to feed the ( existing) play system

[RJSV]

rsjsouza, that was good reading, had to slow down and repeat read. Mind boggling that amount of lack of hope? (A bad phrases, I know).

  In those times, I searched, a little. A 'phone' expert, I did support, for others remote. Very exciting, hmmm yeah I know. But sporadic hobbies were not enough.
Friend said COMMODORE 64, when I babbled about a TRS80. Oh, why that one ?
Anyway, ambition, and a new, 16 color C-64, and I quit those stout beers each evening.

I like, also your mention, of arcades. Something tells me, I wonder some Japanese Co. often went to great efforts, to monitor if not visibly 'protect' a market.
  Several (bigger) players, I bet, had very good sources in distant lands, just for a sense of 'markets', no real action... That's maybe a mark of the play, so to speak:
You don't see em.

  'Columbia', ha! Now, if you remember, was that an Atari-Games arcade?  They looked like some generic Cabs, my neighbor had five or six, there in parking garage.
  RBI baseball ? Mechanical, and what gambling, if any were overt, there...
Still amazed, I maybe w/b depressed, there then.