Jump to content
IGNORED

Our own super, maga, wonder, ultra cart board thing...


matthew180

Recommended Posts

There's something in the works. It's based on my original design, and there are two fine gentlemen enhancing it. I'm not stealing their thunder, because it's still in prototype mode, and hasn't even been tried yet. :-)

 

Wow, that is a nice looking board! Can't wait to see it working. What do you think to cost on that thing will be fully populated?

 

Matthew

Link to comment
Share on other sites

That sure looks beautyful :D

 

I've heard rumors about this baby. I didn't know development was that far already though.

Will this be a 2010 release? It would be nice for Xmas ;)

 

EDIT:

Looking at the picture, I see there is space for an ATmega1284.

The ATmega1284 has 16KB of SRAM, so I'm hoping that some of it will be available in the cartridge space :)

 

You can thank Ksarul for all the reflowing of traces, changing the ROM socket to a more modern non DIP type, and putting in the ATMega logic on the board. Tursi's going to play with the ATMega and see if we can get it to work with GROM.

 

Not sure what Ksarul and Tursi's plans are for the ATmega part, other than it will handle all the GROM stuff. The 512K chip will handle ROM (actually, it's 128K bank switched, with two hard switches, because of limitations on the 74LS379.) The 512K part does expect a 512K chip; there are no jumpers (those chips are very cheap and plentiful, and Ksarul has thousands of them). So, for a 32K program, just program it in the four bank sets (in the 128K segment that you have selected with the hard switches) one of the sets will work. :)

 

It'll be a nice combo board... the ROM flash is easily reprogrammable, and Ksarul and Tursi have jumpers for the debug on the ATMega. Everything is through hole too, which is a bonus for people like me who hate SMD stuff. :)

 

Jon

Link to comment
Share on other sites

There's something in the works. It's based on my original design, and there are two fine gentlemen enhancing it. I'm not stealing their thunder, because it's still in prototype mode, and hasn't even been tried yet. :-)

 

Wow, that is a nice looking board! Can't wait to see it working. What do you think to cost on that thing will be fully populated?

 

Matthew

 

Not sure yet. I just got the first prototype from Ksarul, and I'm checking out the ROM functionality to make sure it works.

 

Ksarul has thousands of the flash ROMs and sockets. The 74LS379 might be able to be replaced by your GAL to fully handle 512K. (I encourage you to e-mail him! He'll likely try and adapt the board!) I haven't even looked at how much the ATMega chips are yet. That part would need to be tested and made to work as well; since it's still a prototype, all we have is a board right now... :-)

Link to comment
Share on other sites

Out of curiosity, have you considered using a microcontroller and its onboard RAM/flash?

 

I looked at microcontrollers, but I'm shying away from them for a few reasons:

 

1. There are already people working on a microcontroller based solution, so I figure I'll try something different so we can see how each method works out.

 

2. I could not figure out if the flash in the various microcontrollers I was looking at could be used as a form of RAM. From the datasheets is seemed like the flash memory was programmed with code and data, then placed in a circuit. It was not clear if the executing code could modify that memory directly, and if so, use it for any purpose.

 

3. I'm really kind of partial to the programmable logic now that I have had a taste of it. I don't have to worry about clock speed so much, or how long a program takes to execute, etc. I only have to worry about propagation delays, which are pretty much always going to be faster than the classic hardware.

 

I used to approach a problem in terms of how I could solve it using a CPU and code. Lately I tend to think about how I would solve the problem with a circuit via a PLD of some sort. And, in cases like the GAL I used in the Bank Switch Mini, the PLD was a *lot* easier and cheaper than using a microcontroller of some sort.

 

Matthew

To each his own. We're doing this because it's fun, and if you're having fun with programmable logic, by all means, keep at it! I personally am rather partial to keeping it all on one chip, and the programmable logic route always seems to have me buying separate memory, whether it be flash, RAM or EPROM. :-)

 

As for the Microchip PIC24/dsPIC33s: The flash is mainly meant for code and fixed data tables. This makes it a great ROM replacement, but not a RAM replacement by any stretch of the imagination. I use the PIC's onboard RAM (16k bytes in the version I'm using) to offer RAM to the console. If I wanted to offer more RAM, I'd have to either sprout an external RAM chip or find a different microcontroller. (I think some of the PIC32s have 32K or more RAM.)

 

That said, the flash is in-circuit programmable using sector-erase and row-program commands. On the PIC24/dsPIC33, you erase 1.5K byte sectors at a time. Each row has 64 24-bit words, and you flash 1 row at a time. (8 rows to a sector.) You can use this flash space to provide a form of NVRAM to the console if you are careful about the handshakes you set up. Since an erase cycle can take up to 20ms, you must have code running from within the console's memory map while an "NVRAM" update occurs. That's nothing new to TIers, though. As I recall, the speech synthesizer also requires that sort of jiggery-pokery. (Or am I misremembering?)

 

The PIC's flash is only good for something like 1000 erase/reflash cycles, so you'd have to wear-level to get decent life out of it. A 64K game in a 256K flash leaves 192K for wear leveling, which is more than plenty. Given all that: $5 for an all-in-one RAM, NVRAM and ROM? You have to admit it's somewhat attractive. :)

 

I won't fault you for going the hardware route. It's fun too. (And if you ever get the F18A done, put me on your order list! I'll take two, minimum!)

Link to comment
Share on other sites

I'd like to see Matthew's 74LS379 GAL replacement on the V6 cart board... that'd be awesome bank switching that whole 512K ROM. :-)

 

Here you go. I attached a zip file that has the VDHL, Chip pin-out report (see what I mean by not being able to control the pin assignments), and the JED programming file so all you need to do is write it to the GAL. Enjoy.

 

Matthew

 

--
-- Matthew Hagerty, Sept 29, 2010 for TI-99/4A projects
--
-- HEX D Flip-Flop with Enable
--
-- Basically a 6 input / 6 output 74LS379
--
-- OE* Should be tied low (you always want the outputs active)
-- CP is active on the risting edge
-- INVERT is active high (a '1' causes inverted output)
--
-- Since inputs are pulled high by the GAL, the INVERT
-- signal can be defaulted to providing inverted outputs
-- simply be leaving it open.  Then a jumper can be used
-- on a board to pull the pin low for non-inverted
-- outputs.  Thus, the jumper should be labeled: INVERT*
--
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;

entity memsel is
 port (
   cp     : in std_logic;
   clken  : in std_logic;
   invert : in std_logic;
   d_in   : in std_logic_vector(0 to 5);
   oe     : in std_logic;
   q_out  : out std_logic_vector(0 to 5)
 );
end;

architecture behavorial of memsel is
 signal reg : std_logic_vector(0 to 5);
begin

 process(cp)
 begin
   if rising_edge(cp) and clken = '0' then
     if invert = '0' then
       reg <= d_in;
     else
       reg <= not d_in;
     end if;
   end if;
 end process;

 q_out <= reg when oe = '0' else (others => 'Z');

end behavorial;

 

                                                                     Page 1
ispLEVER Classic 1.3.00.09.29.09  -  Device Utilization Chart         Wed Sep 29 00:05:21 2010



--------------------------------------------------------------------------------

Module                   : 'memsel'

--------------------------------------------------------------------------------

Input files:

   ABEL PLA file        : memoryselector.tt3
   Device library       : P16V8R.dev

Output files:

   Report file          : memoryselector.rpt
   Programmer load file : memoryselector.jed

--------------------------------------------------------------------------------


                                                                     Page 2
ispLEVER Classic 1.3.00.09.29.09  -  Device Utilization Chart         Wed Sep 29 00:05:21 2010

P16V8R Programmed Logic:
--------------------------------------------------------------------------------



q_out_1_.D   = (  !clken & invert & d_in_1_ 
               #   !clken & !invert & !d_in_1_ 
               #   clken & !q_out_1_.PIN ); " ISTYPE 'INVERT'
q_out_1_.C   = (  cp );
q_out_1_.OE  = (  !oe );

q_out_0_.D   = (  d_in_0_ & !clken & invert 
               #   !d_in_0_ & !clken & !invert 
               #   clken & !q_out_0_.PIN ); " ISTYPE 'INVERT'
q_out_0_.C   = (  cp );
q_out_0_.OE  = (  !oe );

q_out_5_.D   = (  !clken & invert & d_in_5_ 
               #   !clken & !invert & !d_in_5_ 
               #   clken & !q_out_5_.PIN ); " ISTYPE 'INVERT'
q_out_5_.C   = (  cp );
q_out_5_.OE  = (  !oe );

q_out_4_.D   = (  !clken & invert & d_in_4_ 
               #   !clken & !invert & !d_in_4_ 
               #   clken & !q_out_4_.PIN ); " ISTYPE 'INVERT'
q_out_4_.C   = (  cp );
q_out_4_.OE  = (  !oe );

q_out_3_.D   = (  !clken & invert & d_in_3_ 
               #   !clken & !invert & !d_in_3_ 
               #   clken & !q_out_3_.PIN ); " ISTYPE 'INVERT'
q_out_3_.C   = (  cp );
q_out_3_.OE  = (  !oe );

q_out_2_.D   = (  !clken & invert & d_in_2_ 
               #   !clken & !invert & !d_in_2_ 
               #   clken & !q_out_2_.PIN ); " ISTYPE 'INVERT'
q_out_2_.C   = (  cp );
q_out_2_.OE  = (  !oe );



                                                                     Page 3
ispLEVER Classic 1.3.00.09.29.09  -  Device Utilization Chart         Wed Sep 29 00:05:21 2010

P16V8R Chip Diagram:
--------------------------------------------------------------------------------




                                   P16V8R

                        +---------\       /---------+
                        |          \     /          |
                        |           -----           |
                     cp |  1                    20  | Vcc                     
                        |                           |
                d_in_0_ |  2                    19  |                         
                        |                           |
                  clken |  3                    18  |                         
                        |                           |
                 invert |  4                    17  | !q_out_2_               
                        |                           |
                d_in_1_ |  5                    16  | !q_out_3_               
                        |                           |
                d_in_2_ |  6                    15  | !q_out_4_               
                        |                           |
                d_in_3_ |  7                    14  | !q_out_5_               
                        |                           |
                d_in_4_ |  8                    13  | !q_out_0_               
                        |                           |
                d_in_5_ |  9                    12  | !q_out_1_               
                        |                           |
                    GND | 10                    11  | oe                      
                        |                           |
                        |                           |
                        `---------------------------'

                       SIGNATURE: N/A


                                                                     Page 4
ispLEVER Classic 1.3.00.09.29.09  -  Device Utilization Chart         Wed Sep 29 00:05:21 2010

P16V8R Resource Allocations:
--------------------------------------------------------------------------------



       Device        | Resource  |   Design    |
      Resources      | Available | Requirement | Unused
======================|===========|=============|==============
                     |           |             |
Input Pins:           |           |             |
                     |           |             |
         Input:      |     10    |      9      |    1 ( 10 %)
                     |           |             |
Output Pins:          |           |             |
                     |           |             |
         In/Out:     |      8    |      6      |    2 ( 25 %)
         Output:     |      -    |      -      |    -
                     |           |             |
Buried Nodes:         |           |             |
                     |           |             |
         Input Reg:  |      -    |      -      |    -
         Pin Reg:    |      8    |      6      |    2 ( 25 %)
         Buried Reg: |      -    |      -      |    -


                                                                     Page 5
ispLEVER Classic 1.3.00.09.29.09  -  Device Utilization Chart         Wed Sep 29 00:05:21 2010

P16V8R Product Terms Distribution:
--------------------------------------------------------------------------------



           Signal                       |    Pin   | Terms | Terms | Terms
            Name                        | Assigned | Used  |  Max  | Unused
=========================================|==========|=======|=======|=======
q_out_1_.D                               |   12     |   3   |   8   |   5
q_out_0_.D                               |   13     |   3   |   8   |   5
q_out_5_.D                               |   14     |   3   |   8   |   5
q_out_4_.D                               |   15     |   3   |   8   |   5
q_out_3_.D                               |   16     |   3   |   8   |   5
q_out_2_.D                               |   17     |   3   |   8   |   5


    ==== List of Inputs/Feedbacks ====

Signal Name                              | Pin      | Pin Type
=========================================|==========|=========
d_in_0_                                  |    2     | INPUT
cp                                       |    1     | CLK
clken                                    |    3     | INPUT
invert                                   |    4     | INPUT
oe                                       |   11     | OE
d_in_1_                                  |    5     | INPUT
d_in_2_                                  |    6     | INPUT
d_in_3_                                  |    7     | INPUT
d_in_4_                                  |    8     | INPUT
d_in_5_                                  |    9     | INPUT
q_out_5_.PIN                             |   14     | COMB FB
q_out_4_.PIN                             |   15     | COMB FB
q_out_3_.PIN                             |   16     | COMB FB
q_out_2_.PIN                             |   17     | COMB FB
q_out_1_.PIN                             |   12     | COMB FB
q_out_0_.PIN                             |   13     | COMB FB


                                                                     Page 6
ispLEVER Classic 1.3.00.09.29.09  -  Device Utilization Chart         Wed Sep 29 00:05:21 2010

P16V8R Unused Resources:
--------------------------------------------------------------------------------



Pin   |  Pin   |   Product   | Flip-flop
Number |  Type  |   Terms     |   Type
=======|========|=============|==========
  18  |  BIDIR | NORMAL  7   |    D
  19  |  BIDIR | NORMAL  7   |    D

memsel_6bit.zip

Edited by matthew180
Link to comment
Share on other sites

Excellent thread here. I had a lot of fun making those parts fit on the cart board--and changing out the 74LS379 with a GAL is a really good idea which I will now incorporate in the next board revision. It also clears up some more real estate on the board to make routing easier by using the PLCC version, so I plan to go with that. More to follow as I get the changes incorporated.

Link to comment
Share on other sites

Excellent thread here. I had a lot of fun making those parts fit on the cart board--and changing out the 74LS379 with a GAL is a really good idea which I will now incorporate in the next board revision. It also clears up some more real estate on the board to make routing easier by using the PLCC version, so I plan to go with that. More to follow as I get the changes incorporated.

 

Excellent work Ksarul! And it's great having you here ;)

Link to comment
Share on other sites

The Atmega1284's purpose on that board is solely GROM emulation - it's the ultimate extension of my single-chip GROM emulator taken to the ridiculous. The goal (which I need to finish coding as my next project) is to make it writable from the TI (tricky but doable), and to make it respect multiple GROM bases (easily feasible). (GROM read already works just fine).

 

Making it respond as RAM was not something we planned on, since the flash chip will live at the cartridge memory address. But I should have lots of RAM free - if I made some RAM accessible through the GROM port, would that still be valuable?

Link to comment
Share on other sites

Regarding the need for GRAM.

 

I assume use of standard console and the game cartridge slot. So no expansions or use of expansion port (except maybe speech).

 

I think TI would have gone down this lane

 

1. GROM

2. GROM + ROM

3. GROM + ROM + RAM

4. GROM + ROM + GRAM

 

We never saw option 4. And I guess one would have to run out of VDP RAM before implementing GRAM.

 

I think Atarisoft would have gone this way if they have had the need - and before V2.2

 

1. ROM

2. ROM + RAM

 

We never saw option 2, and maybe they would have gone one bank with 4K ROM and 4K RAM (like the Mini Memory Module) and other banks 8K ROM.

 

Bottomline. I think a Mini Memory Module emulation layout, with or without persistent/battery RAM, would be more in demand than GRAM. But sure, let's add GRAM if possible.

 

:)

Edited by sometimes99er
Link to comment
Share on other sites

Right... only reason I'm asking the way I am is that my code specifically has no access to the CPU memory bus, but Retroclouds is right, I have plenty of RAM I won't be using. I guess I'll make it available on one of the GROM bases, and if people want to use it, then it's there. As GRAM it WILL be different from the writable GROM at the rest of the bases, since they will need to use a sequence to erase the flash before writing is possible.

Link to comment
Share on other sites

Right... only reason I'm asking the way I am is that my code specifically has no access to the CPU memory bus, but Retroclouds is right, I have plenty of RAM I won't be using. I guess I'll make it available on one of the GROM bases, and if people want to use it, then it's there. As GRAM it WILL be different from the writable GROM at the rest of the bases, since they will need to use a sequence to erase the flash before writing is possible.

 

How fast would writing to GRAM be compared to let's say VDP memory ?

 

Ofcourse having direct RAM access in the cartridge space would be more easy from a developer point of view.

However, I could image using GRAM as some kind of extra buffer for storing stuff that isn't so time critical.

Kinda like expanded VDP memory :)

Link to comment
Share on other sites

If Tursi is using the original GROM clock in his design, then like real GROMs, both the GROM and GRAM access will be very slow compared to VRAM. GROMs, unlike the VDP, have a READY pin that can cause the CPU to add wait states to the read/write cycles until the GROM is done. With the VDP, *we* have to make sure to not over run it. Since the GROMs run from the 447KHz clock (generated by the VDP), they are slow slow slow.

 

However, because of that READY line which makes GROMs an asynchronous device, we can make our GROM replacements faster. This is the approach I'm going with in my design. Basically my GROM, like the F18A, will be faster than the 99/4A, so my pseudo READY line will never go high and never cause a wait state. In this configuration, the GROM will be as fast as anything else on the 8-bit bus, like the 32K RAM, a standard cartridge ROM, etc.

 

From the time the 9900 puts a valid address on the address bus until it reads the data bus is about 500ns, which is pretty slow (relatively speaking.) You can get 45ns EPROMs these days, and even back in the day most ERPOMs, ROMs, etc. would respond in 150ns to 200ns. I typically clock my PLD stuff at 50MHz, so I have a 20ns cycle, which is plenty of time to respond to a memory request from the 99/4A.

 

Matthew

Link to comment
Share on other sites

However, because of that READY line which makes GROMs an asynchronous device, we can make our GROM replacements faster. This is the approach I'm going with in my design. Basically my GROM, like the F18A, will be faster than the 99/4A, so my pseudo READY line will never go high and never cause a wait state. In this configuration, the GROM will be as fast as anything else on the 8-bit bus, like the 32K RAM, a standard cartridge ROM, etc.

 

Not exactly - unless you modify the console. My pseudo GROM is already faster than the real ones, too. But it doesn't matter - all GROMs respond to all accesses. And so the console GROMs pull the READY line for every access, whether they are providing data or not. You would have to remove all real GROMs from the system (and not add any, ie via a cartridge) in order to see that benefit.

 

It's not certain whether data writes will cause the same delay, though, I have not checked what the GROMs do in that case. The likelihood though is that they will induce the delay, since they do for write address. However, the open question remains because they only hold the ready line for as long as is needed to process the request - since write data is a NOP to them, it may be shorter.

 

GROMs are comparatively slow, but less so than I used to think. It takes about 4 GROM clocks for the average operation, so that's about 9uS. This means you can do a sustained read from GROM of over 100k/S (not including the speed of the uP). Of course, this is about 30 times slower than normal clocking, but when you think about the 4 cycle wait states on most memory (which overlaps the GROM hold), it's only about 8 times as slow.

 

Well, I don't have to expose the RAM if perfection is all that's acceptable. We can just waste it. ;)

Link to comment
Share on other sites

GROMs are comparatively slow, but less so than I used to think. It takes about 4 GROM clocks for the average operation, so that's about 9uS. This means you can do a sustained read from GROM of over 100k/S (not including the speed of the uP). Of course, this is about 30 times slower than normal clocking, but when you think about the 4 cycle wait states on most memory (which overlaps the GROM hold), it's only about 8 times as slow.

 

Well, I don't have to expose the RAM if perfection is all that's acceptable. We can just waste it. ;)

 

100k/S doesn't sound bad, so why waste any RAM ?

 

Another question that comes to mind is, how long will it take for emulators to support it ?

That's a very important thing, because it would allow development of new software before the final product is released ;)

Link to comment
Share on other sites

100k/S doesn't sound bad, so why waste any RAM ?

Another question that comes to mind is, how long will it take for emulators to support it ?

That's a very important thing, because it would allow development of new software before the final product is released ;)

 

I was only being dumb.. it's free so I'll implement it anyway. In truth I have my plan mapped out, but it's going to be hard to get both this and the project I want to show ready for the faire.

 

As for emulation, my GROM side of it I can easily add to Classic99, not sure if I would be adding the programmable flash side. Maybe.. I hadn't thought about it. Classic99's configuration is starting to get complex again.. I might need to fix that. ;) (We'll have documentation for others too, of course!)

Link to comment
Share on other sites

Well, with all the talk lately of the old "super cart" and the VIC20's "mega cart", on top of my involvement with the latest batch of 64K boards, I've been giving serious thought to designing an updated version of such a cart for the 99/4A.

 

The super cart seems to have coupled an 8K RAM at the cart address with the E/A's GROM, so you could load the RAM with a program and run it. Plus is was battery backed, so you could essentially make your own carts without the need to have or burn EPROMs or other programmable chips.

 

This is pretty cool, but it has a few draw backs:

 

1. You can't bank switch. Currently our bank switching technique is triggered by the write-enable (we*) signal, but when you are using a RAM you need to have the we* work like normal.

 

2. Your programs have to run from disk or from the 8K RAM itself.

 

 

The VIC20 Mega Cart looks pretty neat and couples a few things together. It has all the VIC20 carts in ROM and you can select them. It also offers extra RAM which uses a nonvolatile SRAM (nvSRAM) which removes the need for a battery backup and still allows the RAM to survive when power is removed. This is pretty cool!

 

 

My initial thoughts were more in the area of the 99/4A's old super cart, but add some bank switching, plus the nvSRAM like the Mega Cart is using, as well as a programmable GROM to provide the original E/A code, or our own new loader and such. I was not initially thinking of trying to offer a cart that would cram all the existing 99/4A carts into one mega-cart, but maybe that *is* what people want (hence the discussion here.)

 

Ultimately I'd also like to work in some sort of USB interface or miniSD card options so the cart could be loaded / programmed from a PC (personal computer, not necessarily a *Windows* "PC"). At this point the cart would enter the realm of a mega-cart I suppose. Maybe you put this cart into the 99/4A and leave it there, then instead of changing "cartridges" you would change miniSD cards.

 

Keep in mind however, I'm *not* talking about making this like a disk subsystem. The cartridge address space needs to function like a memory, i.e. RAM or ROM, and thus needs to respond in the time-frame of a real memory IC, which is about 200ns or faster. However, there could be some sort of process that copies data from USB or miniSD into a real RAM or something like that. These are some of the details I'd like to kick around here.

 

The other problem to hash out would be how to bank-switch RAM. The cart port has two CRU lines, so I was thinking that maybe use a CRU trigger to enable bank-switching vs. normal write operations, or something like that. There could also be something like a specific "write sequence" to a particular address to get different functionality. Anything is possible.

 

Thoughts, comments, questions, concerns?

 

Matthew

 

 

Matt...

 

I have a couple of questions about "hardware programming"....

 

I am assuming you can combine logic as you see fit and even create virtual Logic IC's that don't exist in the real world. I am pretty sure this is the case so......

 

Would it be possible to create a circular shift register of any size?

 

At power up is it possible that the bits of this register can come up with a preloaded pattern or could your logic load the register with a specific pattern as a part of the power up function?

 

Thanks in advance for the answers...

 

Marc

Link to comment
Share on other sites

Working with programmable logic is basically like having a pile if D flip-flops and AND, NAND, OR, NOR, and INV gates. Also, PLDs (programmable logic devices) like FPGAs have multiplexor blocks and other arrays of various logic already set up for common uses. In theory you can describe anything you could build with discrete logic, i.e. 74LSxxx or CMOS 54xx chips. Of course description languages make this a lot easier, for example, a 13-bit counter (just like we need for GROM emulation) could be described like this:

entity grom_addr is
 port (
   clk   : in std_logic;
   reset : in std_logic;
   en    : in std_logic;
   load  : in std_logic;
   d_in  : in std_logic_vector[0 to 12];
   a_out : out std_logic_vector[0 to 12];
 );
end;

architecture arch of grom_addr is

 signal counter : std_logic_vector[0 to 12];

begin

 process (clk)
 begin
   if rising_edge(clk) then
     if reset = '1' then
       counter <= (others => '0');

     else if load = '1' then
       counter <= d_in;
   
     else if en = '1' then
       counter <= counter + 1;

     end if;
   end if;
 end process;

 a_out <= counter;

end arch;

This describes a 13-bit binary counter with a synchronous reset, load, and count enable, similar to a 74LS161 but not quite as complex. The FPGA compiler will allocate just the number of flip-flops we need for out counter, and in theory it could be as big or small as we want.

 

The only limiting factor to the size of a register is the number of cells in the programmable device. Also, you still have to obey the set-up and hold times, propagation delay, etc. Basically, if you can build it with discrete logic chips then you can do it with a programmable device.

 

It sounds like you are looking for a really large buffer for random noise data in a sound chip or random number generation?

 

As for preloaded at "power up", that's tricky. A PLD responds to events, like inputs changing, a clock signals, etc. There is no way to have "default" values (as we think of them in programming) or detect "power up". To set initial values you have to have an external reset signal that comes in on an input pin. Once you have that signal available, you would usually modify your state machine to set only the values absolutely necessary. The reset in the example above is an example of this, but you can not guarantee that the reset will be the first event. That's why most computers (like the 99/4A) have an external reset signal that is usually discrete parts like an resistor-capacitor (RC) circuit that applies a long (500ms or so) reset signal at power-on.

 

Anyway, does that answer your questions?

 

Matthew

Link to comment
Share on other sites

  • 11 months later...

Hey Matthew -

 

Hate to resurrect an old thread, but I finally got around to burning one of the GAL16V8D's that Ksarul sent me with the code above. A quick question - I know we've been doing (on the interted 74LS379's) a power up bank of the highest bank.

 

On the example above, when burned, we're still doing a power up bank of the highest bank whether inverted or not. Does it make sense for the non inverted power up scheme to power up in the first bank? Can you please compile an example of that for me so I can try it?

 

I'm trying to get a working ROM image with the new board, and, for an example, I put the 16K Neverlander ROM at the top of the 512K chip and left it in inverted status (i.e. I didn't flip it). It shows up on the menu, but no dice getting it to start. I reversed the banks on the off chance that was it, but nada. I then burned an 8K ROM at the very top of the 512K space, and it comes up and runs whether the invert is on or off.

 

If anything, having the non inverted example power up in the lowest bank will let me put stuff at the bottom and simplify my troubleshooting. If we did, for the non invert, allow the power up bank to be the lowest 8K one, and, for inverted, allow the power up bank the be the highest 8K one. Thoughts?

 

Thanks,

Jon

Link to comment
Share on other sites

Using the side port that normally goes to the Pbox is the best approach as you have access to CRU, can add 32K or even AMS, GROM/GRAM like a PGRAM or SGPL card and speech.

 

Really make a box about the size of the Speech box and put all of it into one device.

 

It would even work on the v2.2 TI as you are using the PBox method to by pass most of the problems through normal CRU or RAM or GRAM.

 

Lastly you could put a USB port on it or SATA port or even Video upgrade. The Cartridge port is really the hard way and very limited.

 

This is what Don O'Neil told me was a better method when Western Horizon was manufacturing my RXB Cartridge and why it never got produced.

 

The chips were to expensive at the time. Today that is not a problem, yet no one has gone this route in all these years. Very odd.

Edited by RXB
Link to comment
Share on other sites

Jon, Matthew should have his test boards any day now, so he'll be able to do some validation locally too. I sent him everything he needed to test the ROM side on Thursday.

 

Jon, did you put all three of the minimum required jumpers on the board? ;) The ones you need are listed in the documentation I sent you a while back for review. (I figured you did, but I just had to have a little fun after the wild chase I went on the last time you forgot one.) LOL

 

Thanks for getting at the tests so quickly too!

Edited by Ksarul
Link to comment
Share on other sites

Using the side port that normally goes to the Pbox is the best approach as you have access to CRU, can add 32K or even AMS, GROM/GRAM like a PGRAM or SGPL card and speech.

 

(...)

 

This is what Don O'Neil told me was a better method when Western Horizon was manufacturing my RXB Cartridge and why it never got produced.

 

The chips were to expensive at the time. Today that is not a problem, yet no one has gone this route in all these years. Very odd.

 

There were a couple of game cartridges released on the side port, but the fact is that the side port may be nice from the /developer's/ standpoint, but it rather sucks from the /user's/ standpoint. Most systems already have something plugged into the side port, usually a PEB. Unplugging the PEB just to plug in a cartridge is not only inconvenient, but a little distressing as the flex cable interface tends to get flakey as it is without continuously plugging and unplugging it.

 

If you had something like the speech synth that provided a port (or maybe even a little synth add-on that provided a port under the door ;) ), that might not be so bad, but you limit your market to the people who have that add-on.

 

From my point of view, limited though it is, the cart port is the best place for ROM-based software distribution.

Link to comment
Share on other sites

@Jon: I just got the board from Ksarul late today (Saturday) and I have not had a chance to mess with it. I don't remember much about the details of the GAL, so I'll have to go back and mess with it a little to get my bearings again.

 

I think I remember something about the GAL not having flip-flops with preset or reset inputs, but the GAL itself guarantees that the outputs will be in a known state at power up. I'll have to go check the datasheet again and do some testing.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...