Subject: Chips and EPROMer

From: Owen Brand <[email-masked]>
Date: Mon, 27 Sep 2010 02:24:50 -0400

Looking for some chips.  74LS379----  anyone have some random drawer- 
full of these things? I need a bunch.... I think Matthew might sell  
them at his online store, but I didn't see them listed. (his store is  
actually very cool for us 99ers.... Check it out, seriously)

Also--- I am looking for an EPROM burner.  I remember someone had one  
for sale a while back, but I cannot recall who.... Maybe Jon?  Anyway,  
I run a Win7 PC with all USB outs... Don't know how much that factors  
in to the make and model I will need to get... I DO have a USB->serial  
adapter if needed.  Thanks

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: "Tursi" <[email-masked]>
Date: Mon, 27 Sep 2010 05:36:44 -0700

> full of these things? I need a bunch.... I think Matthew might sell

Guess that's getting to be a pretty obsolete part...

Mouser has 18 in stock for $1.98 each: 
http://www.mouser.com/ProductDetail/NTE/NTE74LS379/?qs=sGAEpiMZZMsagl7BRmp5TRbi3B9%2fYpOoyHlFm3Y0EXE%3d

> adapter if needed.  Thanks

I recently bought a new USB-based programmer for my 64-bit Win7 system, I 
got this one for $149.99:

http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=4282

It's USB powered and works pretty well.

---

From: "Ksarul" <[email-masked]>
Date: Mon, 27 Sep 2010 09:48:43 -0400

Unicorn has them for 1.25, quantity one, 1.23 each for 25, 1.11 each for
100, and 1.00 each for 1,000.  They note that the part has been
discontinued. . .

Jim

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tursi
Sent: Monday, September 27, 2010 8:37 AM
To: [email-masked]
Subject: Re: [TI994A] Chips and EPROMer

Mouser has 18 in stock for $1.98 each: 
http://www.mouser.com/ProductDetail/NTE/NTE74LS379/?qs=sGAEpiMZZMsagl7BRmp5T
Rbi3B9%2fYpOoyHlFm3Y0EXE%3d

---

From: Owen Brand <[email-masked]>
Date: Mon, 27 Sep 2010 11:01:48 -0400

obsolete?  Hopefully it won't disappear forever...

I'd like to think of them as "obscure" and "charming" rather than  
obsolete.... But you're right.  :) they will become increasingly  
difficult to find.  Suppose I should buy a couple hundred

Owen Brand

        **webmaster**
http://www.Opry99er.com

On Sep 27, 2010, at 8:36 AM, "Tursi" <[email-masked]>  
wrote:

> > in to the make and model I will need to get... I DO have a USB- 
> >serial

---

From: Owen Brand <[email-masked]>
Date: Mon, 27 Sep 2010 12:43:07 -0400

Thanks for the link.  These coupled with Tursi's suggested EPROM  
burner will get me a bit closer.  Now.... To find a bunch of small  
EPROMs....

Owen Brand

        **webmaster**
http://www.Opry99er.com

On Sep 27, 2010, at 9:48 AM, "Ksarul" <[email-masked]> wrote:

> Unicorn has them for 1.25, quantity one, 1.23 each for 25, 1.11 each  
> for 100, and 1.00 each for 1,000.  They note that the part has been  
> discontinued. . .
>
>
>
>
>
> Jim
>
>
>
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Tursi

---

From: "Ksarul" <[email-masked]>
Date: Mon, 27 Sep 2010 13:12:11 -0400

Here'a a link for 27 of them. . .

http://cgi.ebay.com/M5L2764K-Mit-64K-EPROM-D2764-TMS2764-AM2764-2764-IC-27p-
/250701565955?pt=LH_DefaultDomain_0
<http://cgi.ebay.com/M5L2764K-Mit-64K-EPROM-D2764-TMS2764-AM2764-2764-IC-27p
-/250701565955?pt=LH_DefaultDomain_0&hash=item3a5efa5003>
&hash=item3a5efa5003

Jim

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Owen Brand
Sent: Monday, September 27, 2010 12:43 PM
To: [email-masked]
Subject: Re: [TI994A] Chips 74LS379

Thanks for the link.  These coupled with Tursi's suggested EPROM burner will
get me a bit closer.  Now.... To find a bunch of small EPROMs....

Owen Brand

       **webmaster** 

http://www.Opry99er.com

 

Jim

  _____  

From:  <mailto:[email-masked]> [email-masked]
[mailto:[email-masked]] On Behalf Of Tursi
Sent: Monday, September 27, 2010 8:37 AM
To: [email-masked]
Subject: Re: [TI994A] Chips and EPROMer

 
<http://www.mouser.com/ProductDetail/NTE/NTE74LS379/?qs=sGAEpiMZZMsagl7BRmp5
TRbi3B9%2fYpOoyHlFm3Y0EXE%3d>
http://www.mouser.com/ProductDetail/NTE/NTE74LS379/?qs=sGAEpiMZZMsagl7BRmp5T
Rbi3B9%2fYpOoyHlFm3Y0EXE%3d

<http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=4282>
http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=4282

---

From: Owen Brand <[email-masked]>
Date: Mon, 27 Sep 2010 13:06:42 -0400

These are the proper ones?  These will work in my cart boards?  If so,  
I'm buying it Now.  :) Already ordered an EPROM burner...

Owen Brand

        **webmaster**
http://www.Opry99er.com

On Sep 27, 2010, at 1:12 PM, "Ksarul" <[email-masked]> wrote:

> Here’a a link for 27 of them. . .
>
>
>
> http://cgi.ebay.com/M5L2764K-Mit-64K-EPROM-D2764-TMS2764-AM2764-2764-IC-27p-/250701565955?pt=LH_DefaultDomain_0&hash=item3a5efa5003
>
>
>
> Jim
>
>
>
> Behalf Of Owen Brand
>> Unicorn has them for 1.25, quantity one, 1.23 each for 25, 1.11  
>> each for 100, and 1.00 each for 1,000.  They note that the part has  
>> been discontinued. . .
>>
>>
>>
>>
>>
>> Jim
>>
>>
>>

---

From: Marc Hull <[email-masked]>
Date: Mon, 27 Sep 2010 11:04:40 -0700 (PDT)

What's up ? You taking over the Funware line ??? ;-)

--- On Mon, 9/27/10, Owen Brand <[email-masked]> wrote:

From: Owen Brand <[email-masked]>
Subject: Re: [TI994A] Chips 74LS379
To: "[email-masked]" <[email-masked]>
Date: Monday, September 27, 2010, 12:06 PM

  

      These are the proper ones?  These will work in my cart boards?  If so, I'm buying it Now.  :) Already ordered an EPROM burner...

Owen Brand
       **webmaster** http://www.Opry99er.com
On Sep 27, 2010, at 1:12 PM, "Ksarul" <[email-masked]> wrote:

    

Jim 

From: [email-masked] [mailto:[email-masked] ] On Behalf Of Owen Brand

Sent: Monday, September 27, 2010
12:43 PM

Subject: Re: [TI994A] Chips
74LS379 

Owen Brand 

       **webmaster**  

http://www.Opry99er.com 

   

Unicorn has them for 1.25, quantity one, 1.23 each for 25, 1.11
each for 100, and 1.00 each for 1,000.  They note that the part has been
discontinued. . . 

Jim 

From:  [email-masked] 
[mailto:[email-masked] ]
On Behalf Of Tursi

Sent: Monday, September 27, 2010
8:37 AM

Subject: Re: [TI994A] Chips and
EPROMer

---

From: "Ksarul" <[email-masked]>
Date: Mon, 27 Sep 2010 14:00:34 -0400

They are-they are 8K by 8 bit EPROMs.  Make sure you ask him to erase them
if they haven't been erased already.  He's a reliable seller out of Romania
that I have dealt with several times in the past.  Shipping is a little
slow, but that is due to the Romanian postal service and the overseas
transport part.  He ships pretty fast when you look at the postmarks.

Jim

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Owen Brand
Sent: Monday, September 27, 2010 1:07 PM
To: [email-masked]
Subject: Re: [TI994A] Chips 74LS379

These are the proper ones?  These will work in my cart boards?  If so, I'm
buying it Now.  :) Already ordered an EPROM burner...

Owen Brand

       **webmaster** 

http://www.Opry99er.com

 

Jim

  _____  

[mailto:[email-masked]] On Behalf Of Owen Brand

Owen Brand

       **webmaster** 

 <http://www.Opry99er.com> http://www.Opry99er.com

On Sep 27, 2010, at 9:48 AM, "Ksarul" < <mailto:[email-masked]>
[email-masked]> wrote:

 

Jim

  _____  

From:  <mailto:[email-masked]> [email-masked] [mailto:
<mailto:[email-masked]> [email-masked]] On Behalf Of Tursi
Sent: Monday, September 27, 2010 8:37 AM
To:  <mailto:[email-masked]> [email-masked]
Subject: Re: [TI994A] Chips and EPROMer

---

From: "Ksarul" <[email-masked]>
Date: Mon, 27 Sep 2010 14:27:25 -0400

I think Kyle has the Funware line locked up nicely-and he does a nice job of
putting the new titles in original cases. . .

Jim

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marc Hull
Sent: Monday, September 27, 2010 2:05 PM
To: [email-masked]
Subject: Re: [TI994A] Chips 74LS379

Owen Brand

       **webmaster** 

http://www.Opry99er.com

 

Jim

  _____  

From: [email-masked] [mailto:[email-masked] ] On Behalf Of
Owen Brand
Sent: Monday, September 27, 2010 12:43 PM
To: [email-masked]
Subject: Re: [TI994A] Chips 74LS379

Owen Brand

       **webmaster** 

 

Jim

  _____  

From: [email-masked] [mailto:[email-masked] ] On Behalf Of
Tursi
Sent: Monday, September 27, 2010 8:37 AM
To: [email-masked]
Subject: Re: [TI994A] Chips and EPROMer

---

From: Owen Brand <[email-masked]>
Date: Mon, 27 Sep 2010 14:13:16 -0400

Ha!!  Nope.  Cooler than that.  :) But you are close... I WILL be  
assembling a bunch of cart boards.

Owen Brand

        **webmaster**
http://www.Opry99er.com

On Sep 27, 2010, at 2:04 PM, Marc Hull <[email-masked]> wrote:

> These are the proper ones?  These will work in my cart boards?  If  
> so, I'm buying it Now.  :) Already ordered an EPROM burner...
>
> Owen Brand
>
>        **webmaster**
> http://www.Opry99er.com
>
>>> each for 100, and 1.00 each for 1,000.  They note that the part  
>>> has been discontinued. . .
>>>
>>>
>>>
>>>
>>>
>>> Jim
>>>
>>>
>>>
>>> From: [email-masked] [mailto:[email-masked] ] On  
>>> Behalf Of Tursi

---

From: "Matthew" <[email-masked]>
Date: Mon, 27 Sep 2010 18:59:05 -0000

> It's USB powered and works pretty well.

I looked at that programmer, but the software triggered my anti-virus software when I hit the "built-in calculator" button (which looked an awful lot like the calc.exe from WinXP - total cop-out), so I didn't buy the hardware.  To their credit they did respond to the email I sent about it and asked what anti-virus I was using (AVG).  I'd be curious to know how it is working for you?

As for the 379's, they are obsolete, as in no manufacturer is making them any more.  When I was preparing to make another run of the 64K boards I had to source them, and this was the first time I tried one of those "bidding" companies that always come up in the search results when you search for IC numbers.  I needed to keep the cost down since it affects the cost of the boards, so I ordered 300 (smallest quantity I could find.)

Thus, I actually have 200 more than I have boards and I'll definitely sell some.  Also, when you buy boards from me, you get the 379 chip with it. :-)

I didn't think they were an in demand item, but I can add them to the CHC store I suppose.  I don't know what you would use them for other than the 64K boards though.

Matthew

---

From: Owen Brand <[email-masked]>
Date: Mon, 27 Sep 2010 15:09:52 -0400

Thanks Matthew... I was not aware that your boards came with the  
chip.  Still, I'd like to have some on hand in case I ever order a  
whole run of boards myself.  I doubt I will ever have the need for 100  
boards, but if I have some time to do it, I'd like to start working on  
the SSGC compendium for cart... Also have plans for Calimari Carl and  
Lemonade Stand... Im pretty good at displaying screens and moving  
stuff around in assembly now... Still trying to find efficient ways to  
utilize my registers--- i have fallen into a bad habit of storing game  
variables in them...

Anyway, Tursi has already done a fantastic job with 2 of the SSGC  
games.... :) He combined his ZomBXB game with Codex's TI Farmer game.   
Love it!!

Owen Brand

        **webmaster**
http://www.Opry99er.com

On Sep 27, 2010, at 2:59 PM, "Matthew" <[email-masked]> wrote:

> I looked at that programmer, but the software triggered my anti- 
> virus software when I hit the "built-in calculator" button (which  
> looked an awful lot like the calc.exe from WinXP - total cop-out),  
> so I didn't buy the hardware. To their credit they did respond to  
> the email I sent about it and asked what anti-virus I was using  
> (AVG). I'd be curious to know how it is working for you?
>
> As for the 379's, they are obsolete, as in no manufacturer is making  
> them any more. When I was preparing to make another run of the 64K  
> boards I had to source them, and this was the first time I tried one  
> of those "bidding" companies that always come up in the search  
> results when you search for IC numbers. I needed to keep the cost  
> down since it affects the cost of the boards, so I ordered 300  
> (smallest quantity I could find.)
>
> Thus, I actually have 200 more than I have boards and I'll  
> definitely sell some. Also, when you buy boards from me, you get the  
> 379 chip with it. :-)
>
> I didn't think they were an in demand item, but I can add them to  
> the CHC store I suppose. I don't know what you would use them for  
> other than the 64K boards though.
>
> Matthew
>
>

---

From: "Tursi" <[email-masked]>
Date: Mon, 27 Sep 2010 13:10:44 -0700

> I looked at that programmer, but the software triggered my anti-virus 
> software when I hit the "built-in calculator" button (which looked an 
> awful lot like the calc.exe from WinXP - total cop-out), so I didn't buy 
> the hardware.  To their credit they did respond to the email I sent about 
> it and asked what anti-virus I was using (AVG).  I'd be curious to know 
> how it is working for you?
>

hehe, yes, it is, but all seems to work for me (and in fact I like the WinXP 
calculator more then the 7 one, so I was kind of glad for it ;) ).

No AV trigger here though.

---

From: Owen Brand <[email-masked]>
Date: Mon, 27 Sep 2010 16:20:18 -0400

Good stuff.  :) I imagine the software is pretty intuitive?  I imagine  
it will allow you to draw the objectcode from a source on your PC and  
it will burn it according to pre-set specs?  What kind of options will  
I have when I am in the software side of it?  Just curious about what  
to expect...

I will not be requiring more than one bank for now, but I will in the  
future.. I'm quite intrigued and eager to get started.

Owen Brand

        **webmaster**
http://www.Opry99er.com

On Sep 27, 2010, at 4:10 PM, "Tursi" <[email-masked]>  
wrote:

> virus

---

From: "Tursi" <[email-masked]>
Date: Mon, 27 Sep 2010 13:39:25 -0700

> I have when I am in the software side of it?  Just curious about what

It took me a bit to work it out, but it's not too bad.

Remember there is no concept of banks on the EPROM itself, so the programmer 
will expect you to provide one file, prebuilt, to burn to the EPROM. So for 
multiple banks, you need to concatenate the files together with the correct 
sizing (that is, exactly 8k each bank, no TIFILES or PROGRAM image headers). 
I usually use a couple of utilities I wrote to pad files to the correct 
size, and concatenate them with COPY in the dos prompt. ;)

---

From: Owen Brand <[email-masked]>
Date: Mon, 27 Sep 2010 17:01:14 -0400

Thanks Tursi... That all makes perfect sense.  I was a bit curious  
about how the "file" is created.... If it's not a program image and if  
it is without TIFILES header, are we talking just about strict and  
straight object code?  Fed directly into VDP and scratchpad RAM  
(assuming it does not utilize the 32k expansion)?

This is pretty cool if that's the case.  :)

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: "Tursi" <[email-masked]>
Date: Mon, 27 Sep 2010 14:30:44 -0700

> (assuming it does not utilize the 32k expansion)?

Well.... yes and no. Cartridges don't actually load, they start running 
right out of the EPROM. That's why there's 8k of CPU memory space reserved 
for them. So it's LIKE running from CPU RAM, except it's CPU ROM. ;) The 
program is just there.

Of course the program is able to load into VDP, scratchpad, whatever it 
likes, but the console doesn't copy the data anyway, it just starts 
executing.

I actually wrote a little tool that takes the output of Editor/Assembler 
(the object file) and assuming it's all AORG data (AORG >6000 for the 
cartridge space) packs it into a binary file that the eprom programmer can 
load. V9T9 cartridge files are also raw dumps and can work, if they are the 
"C.BIN" type, as these have no extra headers either. (C.BIN and D.BIN types, 
like Atarisoft games, will also work on the multi-bank cartridge, if they 
are the first two banks on the EPROM - although G.BIN files are GROM and 
won't work on the current board).

---

From: Owen Brand <[email-masked]>
Date: Mon, 27 Sep 2010 17:49:26 -0400

That's where I was getting tripped up--- I assumed a copy function  
when clearly this is not the case.  Hmm...

Well, if this is the case, one could theoretically create a cart-based  
program which populates the VDP RAM.... For instance, a maze generator  
program which exists in the cart ROM could potentially generate a  
large amount of maze data which writes to VDP RAM. Am I understanding  
this properly?

Tricky stuff... I'm a bit out of my league I guess... But I love the  
"input".  Thanks again

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: "Matthew" <[email-masked]>
Date: Mon, 27 Sep 2010 21:58:01 -0000

You can download the software and try it without actually having the hardware.  Just go download and install it.  You can do everything except read or write chips (obviously).

The software is usually pretty straight forward.  You are reading or writing bytes to the chip, that's it.  You usually have a buffer that contains the data to go into the chip, or where data read from the chip will go (at which point you can save the data to a file).

The software that comes with the programmer I have allows me to select ranges of addresses in the buffer and chip to read/write.  So I don't actually have to concatenate external files into a single file when programming multiple 8K banks into a larger chip (like a x256).  There are a lot of options from that standpoint, but the software really does not have very much to do as far as the user is concerned, so the UI is usually not very complicated to figure out.

Matthew

--- In [email-masked], Owen Brand <owenbrand@...> wrote:
> On Sep 27, 2010, at 4:10 PM, "Tursi" <yahoogroup@...>  
> wrote:
>

---

From: "Matthew" <[email-masked]>
Date: Mon, 27 Sep 2010 22:13:40 -0000

A cartridge is exactly like having 8K more RAM/ROM in the computer, just like when you plug in the 32K expansion in the PEB.

So, without a cartridge plugged in, if you access memory at >6000 to >7FFF you will get nothing.  When a cartridge is plugged in, depending on if the cart has a RAM or ROM, you can either read the memory or read/write the memory.

And, just like any other real RAM/ROM, if the memory contains executable code, i.e. a program you wrote, then it can be executed.  What that program does has absolutely nothing to do with the fact that it resides in the address space of the cartridge.  The programs running from a cartridge have the same access to the machine as any other program running in any other memory.

A ROM in a cartridge is just like the console ROM sitting at addresses >0000 to >1FFF.

As far as creating a program to go into a ROM, you need object code that was compiled with an AORG >6000 statement, which means it is *not* relocatable.  This kind of program does not require a "loader" because there are no addresses to "fix up" (they are all absolute and can be resolved at compile time.)

Until I finish my own compiler (yet another half done project), I'm using the Asm994a assembler, which has an option to compile your program to a cartridge ROM image.  Coupled with Classic99 and your favorite text editor, this makes a very fast way to develop cartridge based programs since Classic99 will reread the binary file when you do a virtual reset.  It is fast and really speeds up debugging.  Once everything is working, you take that same file output by Asm994a and burn it into an EPROM, stick that in your 64K board, and plug it into a real 99/4A.

Now, if you are developing *on* a 99/4A (or via an emulator), then your work flow will be different, but the end result will be the same, i.e. binary non-relocatable object code.

Matthew

--- In [email-masked], Owen Brand <owenbrand@...> wrote:
> On Sep 27, 2010, at 5:30 PM, "Tursi" <yahoogroup@...>  
> wrote:
>

---

From: "Tursi" <[email-masked]>
Date: Mon, 27 Sep 2010 15:46:47 -0700

> when clearly this is not the case.  Hmm...

Just assume the cartridge contains program that is "already" loaded.

The confusion probably comes from the fact that many recent cartridges are 
simply ports of code that run in 32k RAM, so the cartridge is just used as a 
delivery mechanism - the code in the cartridge copies the program to RAM 
then jumps to it. But that's only because these titles were not written for 
cartridge in the first place, they were written to load from disk.

> large amount of maze data which writes to VDP RAM. Am I understanding

Of course. it's a running program, same as you might load from disk, and can 
do anything.

---

From: mark wills <[email-masked]>
Date: Mon, 27 Sep 2010 22:30:19 +0000 (GMT)

<snip>
Well, if this is the case, one could theoretically create a cart-based program 
which populates the VDP RAM.... For instance, a maze generator program which 
exists in the cart ROM could potentially generate a large amount of maze data 
which writes to VDP RAM. Am I understanding this properly?
</snip>

Of course. Think about it. Every time to you use a loop in machine code to draw 
on the screen, you are doing exactly that. You are using code to generate data 
*in VDP*. The fact that your code is in ROM is irrelevant. Try this:

       REF VSBW
       DEF START

START  CLR R0
       LI R2,768
RESET  LI R1,'0'*256
AGAIN  BLWP @VSBW
       DEC R2
       JEQ EXIT
       INC R0
       AI R1,>0100
       CI R1,'9'*256
       JGT RESET
       JMP AGAIN
EXIT   B @EXIT
       END

There you go, you just used a little program to generate a lot of data in VDP 
RAM.

;-)

>Sent: Mon, 27 September, 2010 22:49:26
>Subject: Re: [TI994A] Re: Chips and EPROMer
>
>  
>
>
>That's where I was getting tripped up--- I assumed a copy function when clearly 
>this is not the case.  Hmm... 
>
>
>Well, if this is the case, one could theoretically create a cart-based program 
>which populates the VDP RAM.... For instance, a maze generator program which 
>exists in the cart ROM could potentially generate a large amount of maze data 
>which writes to VDP RAM. Am I understanding this properly?
>
>
>Tricky stuff... I'm a bit out of my league I guess... But I love the "input". 
> Thanks again
>
>Owen Brand
>
>
>       **webmaster** 
>http://www.Opry99er.com
>
>On Sep 27, 2010, at 5:30 PM, "Tursi" <[email-masked]> wrote:
>
>
>

---

From: Owen Brand <[email-masked]>
Date: Tue, 28 Sep 2010 01:11:31 -0400

Thanks man... I am still learning.  All my work thus far has centered  
around displaying 768 bytes on the screen drawn from a labeled chunk  
of data.  This means that I have had no need to create code like  
you're talking about.  Essentially I have just been using Magellan to  
populate my 24x32 screen with whatever I desire and then taking the  
resulting output and plugging it into my screen display routine.  :)  
Its a bit lame, but I am having some successes, so I'm happy.  :)

BTW, any chance we'll see Manic Miner updates when Turboforth is  
complete?  I'm dying to play a demo.  :)

Owen Brand

        **webmaster**
http://www.Opry99er.com

On Sep 27, 2010, at 6:30 PM, mark wills <[email-masked]>  
wrote:

> <snip>
> Well, if this is the case, one could theoretically create a cart- 
> based program which populates the VDP RAM.... For instance, a maze  
> generator program which exists in the cart ROM could potentially  
> generate a large amount of maze data which writes to VDP RAM. Am I  
> understanding this properly?
> </snip>
>
> Of course. Think about it. Every time to you use a loop in machine  
> code to draw on the screen, you are doing exactly that. You are  
> using code to generate data *in VDP*. The fact that your code is in  
> ROM is irrelevant. Try this:
>
>        REF VSBW
>        DEF START
>
> START  CLR R0
>        LI R2,768
> RESET  LI R1,'0'*256
> AGAIN  BLWP @VSBW
>        DEC R2
>        JEQ EXIT
>        INC R0
>        AI R1,>0100
>        CI R1,'9'*256
>        JGT RESET
>        JMP AGAIN
> EXIT   B @EXIT
>        END
>
> There you go, you just used a little program to generate a lot of  
> data in VDP RAM.
>
> ;-)
>
>
>
> Well, if this is the case, one could theoretically create a cart- 
> based program which populates the VDP RAM.... For instance, a maze  
> generator program which exists in the cart ROM could potentially  
> generate a large amount of maze data which writes to VDP RAM. Am I  
> understanding this properly?
>

---

From: Owen Brand <[email-masked]>
Date: Tue, 28 Sep 2010 01:24:38 -0400

Thanks for the input--- and yes... I believe a portion of my confusion  
came from the reason you suggested.... My favorite TI game is this  
way... Neverlander.  While it could conceivably be run from cart (and  
most likely on an unexpanded TI) it is not... I remember talking with  
you about how that cart was done.  I had an unfortunate accident and  
my un-shelled Neverlander cart fell off my shelf and hit the table.  I  
was unable to determine if something came off it, but it no longer  
works... Neverlander shows up on the master select screen, but when  
selected, it freezes and crashes the console.  Sad day.  I am going to  
try to pull the EPROM and insert it into another cart board--- see if  
that fixes it.  :)

Owen Brand

        **webmaster**
http://www.Opry99er.com

On Sep 27, 2010, at 6:46 PM, "Tursi" <[email-masked]>  
wrote:

> based

---

From: Owen Brand <[email-masked]>
Date: Tue, 28 Sep 2010 12:21:23 -0400

To put a finer point on it, I don't mean that every time I display  
something I display all 768 screen positions... It's just that the  
characters I am displaying are all accounted for in DATA.... If I  
display a message like HELLO WORLD, I have either been using the text  
directive or drawing from BYTE data from a label at the end of my  
code.  Therefore, code that creates more data than exists in my source  
is a bit foreign.  I'll try a little collage by defining some  
characters and randomly displaying them on th screen until the screen  
is full.... Maybe define 8-10 characters with unique colors and see  
what kind of coolness ensues.  :)

Owen Brand

        **webmaster**
http://www.Opry99er.com

On Sep 28, 2010, at 1:11 AM, Owen Brand <[email-masked]> wrote:

> Thanks man... I am still learning.  All my work thus far has  
> centered around displaying 768 bytes on the screen drawn from a  
> labeled chunk of data.  This means that I have had no need to create  
> code like you're talking about.  Essentially I have just been using  
> Magellan to populate my 24x32 screen with whatever I desire and then  
> taking the resulting output and plugging it into my screen display  
> routine.  :) Its a bit lame, but I am having some successes, so I'm  
> happy.  :)
>
> On Sep 27, 2010, at 6:30 PM, mark wills  
> <[email-masked]> wrote:
>
>> <snip>
>> Tricky stuff... I'm a bit out of my league I guess... But I love  
>> the "input".  Thanks again
>>
>> Owen Brand
>>
>>        **webmaster**
>> http://www.Opry99er.com
>>

---

From: "Matthew" <[email-masked]>
Date: Tue, 28 Sep 2010 18:33:04 -0000

Think about it like drawing lines.  You might have a list coordinates in your program like:

0,0
5,5
10,0
0,0

That would draw a triangle if you were drawing straight continuous lines from one point to the next (and you could remove the last 0,0 if you used the rule that a line will connect the first and last points.)  The pixels that make up the triangle are no where to be found in your program, no character definitions, etc.  This is a very basic idea of how 3D games and such work, they have a big database of information that describes what to draw, and an algorithm to get that data to the video card to make a frame.

Another idea is something like a maze generator.  You would not store hundreds or thousands of maze layouts in your code.  You have an algorithm that would use a seed value and random numbers to create unique mazes.

Matthew

--- In [email-masked], Owen Brand <owenbrand@...> wrote:
> On Sep 28, 2010, at 1:11 AM, Owen Brand <owenbrand@...> wrote:
> 
> > <markrobertwills@...> wrote:
> >
> >> <snip>
> >> From: Owen Brand <owenbrand@...>

---

From: mark wills <[email-masked]>
Date: Tue, 28 Sep 2010 20:41:44 +0000 (GMT)

> cartridge in the first place, they  were written to load from disk.

Exactly. TurboForth runs from the ROM in the cartridge. It only uses 888 bytes 
in low CPU RAM (at the moment) leaving >31K free for your programs ;-)

Mark

---

From: mark wills <[email-masked]>
Date: Tue, 28 Sep 2010 20:47:21 +0000 (GMT)

>BTW, any chance we'll see Manic Miner updates when Turboforth is complete?  I'm 
>dying to play a demo.  :) 
>

Yes, it's in the plan ;-) I've caught myself thinking about it a few times, 
which is normally a bad sign ;-)

I've even considered doing it in Forth, as it would be a lot easier...

Mark

---

From: mark wills <[email-masked]>
Date: Tue, 28 Sep 2010 21:34:16 +0000 (GMT)

Here's a nice example of code that does a lot of screen work.

You can paste this into ED/AS with classic99 - should assemble fine. Run with 
option 3 using START as the program name.

Mark

*
* KALEIDOSCOPE - M.WILLS 2006 - ENJOY
 
  DEF START

* LOAD VDP REGISTERS
START  LIMI 0        * DISABLE INTERRUPTS
  
       LWPI WSPACE   * SET WORKSPACE
  
       LI  R1,VDPDAT * ADDRESS OF VDP REGISTER DATA
       LI  R2,8      * NUMBER OF REGISTERS TO WRITE
RGLOOP MOV  *R1+,R0  * GET DATA IN R0
       BL  @VWTR     * WRITE THE REGISTER
       DEC  R2       * DECREMENT COUNTER
       JNE  RGLOOP   * IF NOT FINISHED LOAD NEXT REGISTER

* LOAD COLOUR TABLE
       LI  R0,>0380  * COLOUR TABLE
       LI  R1,COLOUR * ADDRESS OF COLOUR DATA
       LI  R2,16     * LENGTH OF TABLE
       BL  @VMBW

* LOAD CHARACTERS
       LI  R3,16     * DEFINE 16 CHARACTERS
       LI  R0,>800   * ADDRESS OF ASCII 0
NXTCHR LI  R1,CHRDAT * ADDRESS OF CHARACTER DATA
       LI  R2,8      * 8 BYTES TO WRITE
       BL  @VMBW     * WRITE THEM
       AI  R0,16*8   * NEXT CHARACTER
       DEC  R3       * DECREMENT COUNTER
       JNE  NXTCHR   * REPEAT IF NOT FINISHED

* MAIN PROGRAM
       LI   R0,>01E0 * TURN ON SCREEN
       BL   @VWTR

       CLR  R6       * ROM ADDRESS
       LI  R9,20
       LI  R8,1      * MAXIMUM PIXELS PER LINE

RPT    LI  R1,>1000   * ASCII CHARACTER

       LI  R3,SCRN    * BUFFER ADDRESS
       LI  R5,12      * 12 LINES
XL     MOV  R8,R4     * 4 TIMES PER LINE MAX
  
XR     MOVB *R6+,R7   * GET A BYTE FROM ROM
       ANDI R6,>1FFF  * RESTRICT ROM ADDRESS
       SWPB R7        * GET IN LOW BYTE
       ANDI R7,>000F  * CLIP VALUE FROM ROM
  
       A  R3,R7       * OFFSET INTO BUFFER
       MOVB R1,*R7    * LOAD BUFFER
  
       AI  R1,>1000
  
       DEC  R4        * X REPEAT
       JNE  XR        * IF NOT DONE 4 THEN REPEAT
  
       AI  R3,32      * MOVE DOWN A LINE
       DEC  R5        * Y COUNT
       JNE  XL        * REPEAT IF NOT DONE 12 LINES
  
* COPY THE BUFFER IN OPPOSITE SIDE OF SCREEN, MIRROR IMAGE
       LI  R0,SC       * BUFFER ADDRESS
       LI  R1,SCRN+31  * BUFFER ADDRESS, OPPOSITE SIDE
       LI R2,12        * LINE COUNT
  
NXTL   MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
       MOVB *R0+,*R1
       DEC  R1
  
       AI  R0,16       * MOVE SOURCE DOWN TO NEXT LINE
       AI  R1,48       * MOVE DESTINATION DOWN TO NEXT LINE
       DEC  R2         * DONE ALL LINES?
       JNE  NXTL       * REPEAT IF NOT
  
* COPY TOP HALF OF SCREEN TO LOWER HALF, MIRROR IMAGE
       LI  R0,SCRN     * BUFFER ADDRESS, TOP
       LI  R1,SCRN+736 * BUFFER ADDRESS, BOTTOM
       LI  R3,12       * 12 LINES
NXTLIN LI  R2,16       * 16 WORDS PER LINE
NXTWRD MOV  *R0+,*R1+  * COPY A WORD
       DEC  R2         * DONE A LINE?
       JNE  NXTWRD     * IF NOT, DO NEXT WORD
       AI  R1,-64      * MOVE UP ONE LINE (BOTTOM HALF)
       DEC  R3         * DECREMENT LINE COUNT
       JNE  NXTLIN     * DO ANOTHER LINE

* WRITE THE BUFFER TO THE SCREEN
       LI  R0,0        * VDP ADDRESS
       LI  R1,SCRN     * SOURCE BUFFER ADDRESS
       LI  R2,768      * WRITE WHOLE SCREEN
       BL  @VMBW       * DO IT
  
* EMPTY THE BUFFER
       LI  R0,SCRN     * BUFFER ADDRESS
       LI  R1,>2020    * TWO SPACE CHARACTERS
       LI  R2,768      * 768 BYTES TO WRITE
NXT    MOV  *R1,*R0+   * MOVE A WORD
       DECT  R2        * DECREMENT WORD COUNT
       JNE  NXT        * LOOP IF NOT DONE

* DELAY
       MOV  @DELAY,R0  * SMALL DELAY
       CI  R0,0
       JEQ  SETUP
       CI  R0,16300
       JEQ  SETDWN
DLY    DEC  R0
       JNE  DLY
       JMP  OUT
SETUP  LI  R0,100
       MOV  R0,@DELDIR
       JMP  OUT
SETDWN LI  R0,-100
       MOV  R0,@DELDIR
OUT    A  @DELDIR,@DELAY

* REPEAT FROM BEGINNING
       DEC  R9          * DECREMENT OUTER LOOP COUNTER
       JNE  RPT         * LOOP AGAIN IF NOT 0
       LI  R9,20        * ELSE RE-LOAD IT

       A  @MODE,R8      * INCREASE PIXELS PER LINE COUNT EITHER UP OR DOWN
       CI  R8,11        * HAVE WE JUST DONE 10 PER LINE?
       JNE  NXTTST      * IF NOT, DO NEXT TEST
       MOV  @DOWN,@MODE * ELSE START COUNTING DOWN
NXTTST CI  R8,1         * HAVE WE JUST DONE 1 PER LINE
       JNE  OUT1        * IF NOT DO THE LOOP AGAIN
       MOV  @UP,@MODE   * OTHERWISE START COUNTING UP

       LIMI 2
       LIMI 0
  
OUT1   B  @RPT   * DO THE WHOLE THING AGAIN

*---------------------------------------------------------
* VDP UTILITY ROUTINES

* VDP ADDRESSES:
VBLNK EQU >83D7 * VERTICAL BLANK COUNTER
VDPR  EQU >8800 * VDP READ REGISTER
VDPW  EQU >8C00 * VDP WRITE REGISTER
VDPA  EQU >8C02 * VDP ADDRESS REGISTER

* VDP SINGLE BYTE READ
VSBR   SWPB R0
       MOVB R0,@VDPA
       SWPB R0
       MOVB R0,@VDPA
       NOP
       MOVB @VDPR,R1
       RT

* VDP MULTIPLE BYTE WRITE
VMBR   SWPB R0
       MOVB R0,@VDPA
       SWPB R0
       MOVB R0,@VDPA
       NOP
VMBR1  MOVB @VDPR,*R1+
       DEC R2
       JNE VMBR1
       RT

* VDP SINGLE BYTE WRITE
VSBW   ORI R0,>4000
       SWPB R0
       MOVB R0,@VDPA
       SWPB R0
       MOVB R0,@VDPA
       NOP  * DELAY
       MOVB R1,@VDPW
       RT

* VDP MULTIPLE BYTE WRITE
VMBW   ORI R0,>4000
       SWPB R0
       MOVB R0,@VDPA
       SWPB R0
       MOVB R0,@VDPA
       NOP
VMBW1  MOVB *R1+,@VDPW
       DEC R2
       JNE VMBW1
       RT

* VDP WRITE TO REGISTER
VWTR   ORI R0,>8000
       SWPB R0
       MOVB R0,@VDPA
       SWPB R0
       MOVB R0,@VDPA
       RT

* PROGRAM DATA:
* SCREEN BUFFER
SCRN   BSS  32*24
       EVEN
  
* COLOR TABLE DATA
COLOUR DATA >3020,>3040,>5060,>7080,>90A0,>B0C0,>D0E0,>F0C0
       EVEN
  
* VDP REGISTER DATA
VDPDAT DATA >0180,>0000,>0200,>030E,>0401,>0506,>06D0,>0744
       EVEN
  
* CHARACTER DATA
CHRDAT DATA >FFFF,>FFFF,>FFFF,>FFFF
       EVEN
  
UP     DATA 1
       EVEN
  
DOWN   DATA -1
       EVEN
  
MODE   DATA 1  * INITIAL COUNT DIRECTION
       EVEN

DELAY  DATA >8000
       EVEN
  
DELDIR DATA -256
       EVEN
  
WSPACE BSS  32 * RESERVE SPACE FOR WORKSPACE

       END

---

From: Owen Brand <[email-masked]>
Date: Tue, 28 Sep 2010 21:47:11 -0400

Forth..... The final frontier.  :) you know, it would be pretty  
awesome if you wrote it in turboforth....  It could be the  
demonstration of the power of the language. :) you could even document  
some of the game development as a sort of step-by-step language  
tutorial.  :) very interesting idea.  Let's hear that speech!!!!

Owen Brand

        **webmaster**
http://www.Opry99er.com

On Sep 28, 2010, at 4:47 PM, mark wills <[email-masked]>  
wrote:

> Yes, it's in the plan ;-) I've caught myself thinking about it a few  
> times, which is normally a bad sign ;-)
>

---

From: "hexbus" <[email-masked]>
Date: Wed, 29 Sep 2010 02:40:36 -0000

Unicorn Electronics always was able to get me some 74LS379s... they have a monthly newsletter with coupons.  I think I paid like .77 for 130 of them (to put me over the $100 theshhold to use the $10 coupon).  Got a mix of Motorola and some other brand.

Rochester Electronics also can source them pretty easily... they got me actual TI ones for one of the first runs of the 64K boards.  The TI ones actually powered up in a pretty consistent defined state.  The Motorola one and the other ones were a crapshoot.  (Yes, I know you shouldn't assume anything... <g>)

I like Matthew's use of a GAL, and he did post the code for it on his webpage... I'm assuming you still have to assign the pin #'s to the labels somehow. :)    I just don't know the GAL programming language yet.  One of my EPROM programmers should be able to program those chips... either my parallel or USB one.

I just hate the SMT stuff, and wish someone would create a user friendly hobbyist way of assembling the boards.  Hats off to people like Richard Bell who did it by hand (the IDE boards, and such.)

Jon

--- In [email-masked], Owen Brand <owenbrand@...> wrote:
> On Sep 27, 2010, at 8:36 AM, "Tursi" <yahoogroup@...>  
> wrote:
>

---

From: "Matthew" <[email-masked]>
Date: Wed, 29 Sep 2010 03:52:35 -0000

> Unicorn Electronics always was able to get me some 74LS379s... they have a monthly newsletter with coupons.  I think I paid like .77 for 130 of them (to put me over the $100 theshhold to use the $1…

Unicorn bumped their price after you bought them out. ;-)  They were at about $1.11 each when I was looking.

> Rochester Electronics also can source them pretty easily... they got me actual TI ones for one of the first runs of the 64K boards.  The TI ones actually powered up in a pretty consistent defined s…

Well, when you start getting into the hardware description languages (HDL) and programmable logic devices (PLD), you realize that the "power on" state does not really exist.  How they power on will totally depend on how the silicon in the chips happens to come together.  Until you actually pulse the clock pin, the state is unknown.

> I like Matthew's use of a GAL, and he did post the code for it on his webpage... I'm assuming you still have to assign the pin #'s to the labels somehow. :)    I just don't know the GAL programming…

The Lattice tools I used actually assigned the inputs and outputs to the pins automatically and gave me the pin-out.  This was not always a good thing though, since changing the VHDL caused the input and output assignments to change, which meant changing the schematic and board.

When working with FPGAs you can assign the outputs to specific pins and I spent a lot of time trying to figure out how to do the same thing with the GAL.  However I still have not figured it out and I don't know if it is even possible with a GAL.

As for the "language" of a GAL, you use the same HDL you would use for an FPGA, CPLD, or any other programmable logic, i.e. VHDL or Verilog.  You are only restricted as to what you can describe based on the target chip.  For the GAL, you can't implement anything that requires a register, like a state machine, or any initial values for inputs or outputs.  For that you would need to step up to something like a CPLD or FPGA.  A GAL, like a standard logic chip, sets its outputs in response to inputs.  The GAL does have active pull-ups on the inputs though, and guarantees the outputs are all high at power up, which is something standard logic chips can not do.

My low-end, no longer supported, parallel port only, can't run on a CPU faster than 800MHz programmer supports the GAL I selected, so I'm sure yours will too. ;-)

> I just hate the SMT stuff, and wish someone would create a user friendly hobbyist way of assembling the boards.  Hats off to people like Richard Bell who did it by hand (the IDE boards, and such.)

SMD is really not hard and you should give it a try.  You have a much larger selection of parts, and these days the SMD stuff is usually cheaper than the through-hole parts (if you can even get a through-hole version of the part.)  They use less power too, and you can cram more on a given size circuit board.

Just do a youtube search for SMD soldering and watch some people do stuff you did not think possible with a soldering iron or hot-air rework station (I got a nice one for only $130.)

Also, check out the SMD soldering tutorials on SparkFun:

http://www.sparkfun.com/commerce/tutorials.php

They will give you confidence you didn't have.  When I build my bank switch mini, the 0603 parts were the least of my problems.

Matthew