Jump to content

Photo

Random F18A questions

F18A

206 replies to this topic

#26 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 12,478 posts
  • Location:워싱턴 주

Posted Mon Jun 24, 2013 10:04 PM

Also, if someone wanted to dig into the guts of the F18A, there is a 1MB flash on board and about 600K of it sits empty. That could be used for a RAM-disk, non-volatile storage, or even extra display memory (with some GPU coding). A standard library could make it very useful for really fast storage.


Awwwww Maaaaaaaaaaaaaaan! You just had to go hang that carrot out there! :-D
Hello? Any programmers in the house?

#27 Opry99er ONLINE  

Opry99er

    Quadrunner

  • 9,797 posts
  • Location:Hustisford, WI

Posted Tue Jun 25, 2013 12:03 AM

Ooooooooooh... 600k RAM disk? :) That's worth getting excited about. :)

Wonder if the HRD loader could be a good template there (with alternate addressing of course).... It has Funnelweb built right into it. :)

#28 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,167 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Jun 25, 2013 12:46 AM

Desperately need? No, just desperately WANT! You see to me, the partial (windowed view) in TI-W/BA-W is a royal P.I.T.A. If I mistype something, I may miss the mistake. If I can ACTUALLY SEE the whole page as it's intended to be viewed, life is much easier. Besides, is it really a crime to actually want the TI to be USEFUL? I'll never be able to cruise the Internet on it, but I'd really like to use it for more than a doorstop.


Well, I can't address the comments made about loadable file size (as easily), but the point that I was trying to make is that you do not need extra VRAM to display 80-columns on the F18A. As Tim mentioned, if we just update the 40 column editor to display in 80 columns, you're done, no extra VRAM required. Many people found Funnelweb useful without a 9938, it would be the same program but with an 80 column editor. ;)



#29 Willsy OFFLINE  

Willsy

    River Patroller

  • Topic Starter
  • 3,075 posts
  • Location:Uzbekistan (no, really!)

Posted Tue Jun 25, 2013 1:32 AM

I'm pretty sure I have the complete funnelweb source code...

#30 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 12,478 posts
  • Location:워싱턴 주

Posted Tue Jun 25, 2013 9:01 AM

Ooooooooooh... 600k RAM disk? :) That's worth getting excited about. :)



Yeah, ya think? Man I'm salivating at the prospect!!! Who said you can't teach this old TI Dog new tricks? Between all these messages of 600K RAM disks and 80 column support, I see the old girl still has some life left in her.

#31 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 12,478 posts
  • Location:워싱턴 주

Posted Tue Jun 25, 2013 9:03 AM

... if we just update the 40 column editor to display in 80 columns, you're done, no extra VRAM required...


WORKS FOR ME! :thumbsup:

#32 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,156 posts

Posted Tue Jun 25, 2013 9:59 AM

I'm pretty sure I have the complete funnelweb source code...

The following information is from my Jan 2010 recovery of source disks sent to me by the author. While I was able to recover the files I do not recall taking steps to reassemble everything. I am fairly certain I released the recovered source to WHT though I cannot find a final 'distribution' image in my folders nor any records of doing so. I'd be interested if you have some different or complimentary files.

@CFGMISC.SNT - fully recovered
@DR40-1.SNT - fully recovered
@DR80-1.SNT - fully recovered
@FWLOAD.SNT - TWEDMF/S is damaged; 256 bytes of source lost. I replaced the source sector with another good sector so the file is readable but contains erroneous source.
CHRFILES.ZIP - from WHT
ED40_lng.ZIP - from WHT
ED40_min.ZIP - from WHT
EDRNG_80.ZIP - from WHT

Files and disks were recovered using the following methods:
1. Track copy via HyperCopy
2. Sector copy via Birdwell's DSKU program, 1 or more sectors at a time.
3. FDR recreation using disk maps and file reports
4. File reconstruction by copying good sectors into a recovered file to allow the file to be read.
5. Removal of media from the protective jacket to minimize media surface destruction from the inside protective liner.
6. Manual slow-down of disk rotational speed
7. Insertion of good disk to read VIB; insertion of bad disk to read sectors beyond destroyed track 0.

#33 Opry99er ONLINE  

Opry99er

    Quadrunner

  • 9,797 posts
  • Location:Hustisford, WI

Posted Tue Jun 25, 2013 12:34 PM

Hey Matthew, I am just curious how one would address that 600k... Is it immediately addressable or would it require further FPGA work? Forgive my ignorance here. I am not very familiar with FPGA. :)

#34 slinkeey OFFLINE  

slinkeey

    Dragonstomper

  • 504 posts
  • Not a Gamer
  • Location:Racine, WI

Posted Tue Jun 25, 2013 12:46 PM

WORKS FOR ME! :thumbsup:


Sounds like a good opputunity to get your feet wet in programming... :P

Edited by slinkeey, Wed Jun 26, 2013 9:12 AM.


#35 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,535 posts
  • Location:Castaic, California

Posted Tue Jun 25, 2013 2:14 PM

Hey Matthew, I am just curious how one would address that 600k... Is it immediately addressable or would it require further FPGA work? Forgive my ignorance here. I am not very familiar with FPGA. :)


I'm not sure what you are asking when you say "FPGA work". An FPGA is a Field Programmable Gate Array, which is *basically* a chip packed full of hardware logic gates and other digital building-blocks that can be configured via a "bit stream", when power is applied, that describes how to inter-connect the various gates and blocks. This allows the FPGA to "become" whatever hardware circuit is described by the bit-stream.

Typically the FPGA's configuration is SRAM-based, so when you power off the FPGA is loses its configuration. That is why the FPGA needs a flash-EEPROM device to load its bit stream from when it powers up. This is also what makes them "Field Programmable".

The F18A uses an FPGA as the main logic chip since it allowed me to describe the original functionality of the 9918A VDP, plus add the enhancements. This is where the "F", as in FPGA, in F18A comes from. The "18A" is from the 9918A VDP.

So, from the standpoint of needing to do something with the FPGA or its bit stream to support accessing the 600K, nothing needs to be done, the hardware part is ready to go.

From a software standpoint, some routines need to be written. I'd be willing to do the F18A specific parts, but I'm not going to go off and invent the software interface between the 99/4A and F18A. I'd like to get input from people who have much more extensive disk experience on the 99/4A to make some suggestions.

The F18A flash ROM is 1MB (M25P80 for those who want to dig up the datasheet), and the current bit stream and ROM "extras" take up about half of that (or a little less). Technically there is over 600K available, comfortably 500K. The flash is rated at "more than 100,000 program/erase cycles per sector" and "more than 20 years' data retention".

I'm not sure if some sort of FAT-file-system would be necessary, but being able to grow and shrink file sizes without being wasteful seems like it would be a good thing to do.

Maybe the PAB system could be used? But maybe it is too much a pain in the ass though. To me, simple is better. A "name based" system seems best, with a minimal set of functions: open, close, read, write, seek, delete. You can't seek past the end of the file, and reading/writing always happens at the current offset. You would get either "success" or "disk full" as return values. I'm not sure if directories would be necessary, and I have not thought about how you would get a list of files.

Anyway, that's my hasty take on it. Comments? Suggestions?


#36 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 12,478 posts
  • Location:워싱턴 주

Posted Tue Jun 25, 2013 4:06 PM

Sounds like a goos opputunity to get your feet wet in programming... :P


Dude, these guys are so far over my head it isn't funny. I just wrote my first BASIC program in decades yesterday... and it's not much to look at, so assembly is light years ahead of where I'm at. In fact the last time I even used a sector editor was 1989!
I've forgotten most of what I've ever learned! I also have work, and have family obligations which preclude any of that type of in-depth activity. I also learned a long time ago from a young Mr. Tormanen that a 13-15 year old kid could out-code me. It was then that I gave up any illusions of being a decent code hacker.

#37 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,535 posts
  • Location:Castaic, California

Posted Tue Jun 25, 2013 4:35 PM

It sounds more like you defeated yourself. True, coding takes time to learn and you need to use it every now and then to stay somewhat proficient, but it is not difficult. Also, I promise that everyone here has a life, kids, day job, etc. Sometimes the hobby bubbles to the top and we get some time to hack on things, other times things sit idle for months (or years). Contribute where you can and make sure you are having a good time. Moral support and enthusiasm certainly count! But if you want new hardware/software, I advise you to not hold your breath. ;-)


#38 RXB ONLINE  

RXB

    River Patroller

  • 3,241 posts
  • Location:Vancouver, Washington, USA

Posted Tue Jun 25, 2013 6:34 PM

Go with RXB or XB and then if you have time try GPL as it is much more easy to write then Assembly as GPL commands are XB commands with different syntax.
Examples:
XB - CALL CLEAR  ! SPACE CHARACTER IS 32
GPL - ALL 32
XB - CALL HCHAR(1,2,44,10)
GPL - FMT
		  ROW 0
		  COL 1
		  HCHA 10,44
		  FEND
XB - CALL GCHAR(9,7,G)
GPL - FMT
		  ROW 8
		  COL 6
		 FEND
		 (CB IS CHARACTER BUFFER AND HAS THE VALUE)

That is just some easy to do examples.

#39 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Tue Jun 25, 2013 8:24 PM

Maybe the PAB system could be used? But maybe it is too much a pain in the ass though. To me, simple is better. A "name based" system seems best, with a minimal set of functions: open, close, read, write, seek, delete. You can't seek past the end of the file, and reading/writing always happens at the current offset. You would get either "success" or "disk full" as return values. I'm not sure if directories would be necessary, and I have not thought about how you would get a list of files.

Anyway, that's my hasty take on it. Comments? Suggestions?


You are going to have trouble getting any legacy software to "get to" your RAM disk as the DSRLNK routine looks for it via CRU and expects to hand off to a DSR. Neither of which you have. VDP memory is outside the scope of DSRLNK (at least scanning it for a device anyway.) Your more or less going to have to come up with an assembly routine (or a DSR if you will) that resides in memory or perhaps cart space or hack an EPROM and CRU decode circuitry to your F18 board. Or you could try and patch all of the existing software (which would be a big job obviously.)

#40 RXB ONLINE  

RXB

    River Patroller

  • 3,241 posts
  • Location:Vancouver, Washington, USA

Posted Tue Jun 25, 2013 8:50 PM

You are going to have trouble getting any legacy software to "get to" your RAM disk as the DSRLNK routine looks for it via CRU and expects to hand off to a DSR. Neither of which you have. VDP memory is outside the scope of DSRLNK (at least scanning it for a device anyway.) Your more or less going to have to come up with an assembly routine (or a DSR if you will) that resides in memory or perhaps cart space or hack an EPROM and CRU decode circuitry to your F18 board. Or you could try and patch all of the existing software (which would be a big job obviously.)


Well we do have READ, WRITE, OPEN, CLOSE, LOAD, SAVE, VERIFY and STATUS.
Now SCRATCH record does not work for CS1 or CS2 but we would use this type of simple storage like DSR.
XB RAMDISK was a routine that used the LOWER 8K as a drive device for storage. So we could do the same method for access with a DSR.

Nice thing about that is XB or Basic use the GPLLNK DSR and would find it every time. Bit more of a problem and work for Assembly but that is always true.

#41 Willsy OFFLINE  

Willsy

    River Patroller

  • Topic Starter
  • 3,075 posts
  • Location:Uzbekistan (no, really!)

Posted Wed Jun 26, 2013 1:06 AM

You are going to have trouble getting any legacy software to "get to" your RAM disk as the DSRLNK routine looks for it via CRU and expects to hand off to a DSR. Neither of which you have. VDP memory is outside the scope of DSRLNK (at least scanning it for a device anyway.) Your more or less going to have to come up with an assembly routine (or a DSR if you will) that resides in memory or perhaps cart space or hack an EPROM and CRU decode circuitry to your F18 board. Or you could try and patch all of the existing software (which would be a big job obviously.)


Yeah, I was thinking about that. The TI system expects a device at a certain memory address (can't remember DSR space, is it >4000?) and each DSR is mapped into the same address one at a time via the CRU interface. So basically, a system that uses DSRLNK et all to access is out, as far as I can see, since extra hardware, in the form of a PEB card or something that sits on the side-port would be required (as far as I know, (could be wrong) a DSR cannot sit on a cartridge, since the cart is mapped to >6000 and that aint where the TI looks for a DSR).

So, you'd be looking at loading a set of drivers from floppy/HD/RAM disk/CF7 in order to 'unlock' access to the flash on the F18. This is fine, as long as we accept that 'standards compliant' code could not access the F18's flash, so you couldn't use OPEN, INPUT, PRINT#, CLOSE etc from BASIC (for example) to access it. It could be accessed from XB with a suitably loaded libray that provided custom CALL LINKs to provide access.

A similar library would provide access to machine coders. But as I say, since there's no DSR, I don't see a way to make it work like a standard device (e.g. RAM disk) which "just works".

#42 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Wed Jun 26, 2013 5:36 AM

Well we do have READ, WRITE, OPEN, CLOSE, LOAD, SAVE, VERIFY and STATUS.
Now SCRATCH record does not work for CS1 or CS2 but we would use this type of simple storage like DSR.
XB RAMDISK was a routine that used the LOWER 8K as a drive device for storage. So we could do the same method for access with a DSR.

Nice thing about that is XB or Basic use the GPLLNK DSR and would find it every time. Bit more of a problem and work for Assembly but that is always true.



how can the GPL DSRLNK find a device located off the buss that has neither a standard header nor any DSR memory ?

Edited by marc.hull, Wed Jun 26, 2013 7:33 AM.


#43 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,535 posts
  • Location:Castaic, California

Posted Wed Jun 26, 2013 7:08 AM

Yeah, the bit about not having a DSR in the CRU space is a problem in trying to make it fit seamlessly. For XB it might be possible to "fake it" by loading some assembly that patches in a DSR somehow, but I really don't know at this time. For assembly code you would have a blob of code to load up to the F18A VRAM / GPU, and a set of functions to use.

#44 retroclouds OFFLINE  

retroclouds

    Stargunner

  • 1,621 posts
  • Location:Germany

Posted Wed Jun 26, 2013 8:58 AM

Mini Memory has some commands in TI Basic to save and load from the 4K RAM on the cartridge. How did they do that? Is a DSR being used or is that a GPL solution?

#45 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 12,478 posts
  • Location:워싱턴 주

Posted Wed Jun 26, 2013 9:19 AM

Mini Memory has some commands in TI Basic to save and load from the 4K RAM on the cartridge. How did they do that? Is a DSR being used or is that a GPL solution?

Interesting question, I'm looking to see what the answer is as well. I notice the CF7+ / Nano-PEB does the same thing.

BTW - How rare are Mini-Memories? What is considered a decent price-range?

#46 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,535 posts
  • Location:Castaic, California

Posted Wed Jun 26, 2013 9:34 AM

Well, custom calls in BASIC or XB are not really the problem. A "CALL LINK" to access the new drive would be straight forward. I was more referring to a way to get the standard OLD, SAVE, PRINT, etc. to work with the new drive. That would require a standard DSR I believe, or a patched / hacked hook installed somewhere. I think.

#47 retroclouds OFFLINE  

retroclouds

    Stargunner

  • 1,621 posts
  • Location:Germany

Posted Wed Jun 26, 2013 9:42 AM

Some details on Mini Memory can be found here: http://www.mainbyte....carts/mini.html

There for example is a command called SAVE MINIMEM

#48 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 12,478 posts
  • Location:워싱턴 주

Posted Wed Jun 26, 2013 9:57 AM

Some details on Mini Memory can be found here: http://www.mainbyte....carts/mini.html

There for example is a command called SAVE MINIMEM


Hey Thanks. I'm off to check it out now.

#49 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Wed Jun 26, 2013 10:57 AM

Mini Memory has some commands in TI Basic to save and load from the 4K RAM on the cartridge. How did they do that? Is a DSR being used or is that a GPL solution?


There is a header entry and DSR for MINIMEM in the cart space. Hence the earlier suggestion for a DSR in a cart ;-).... This solution pretty much strands you at the TI BASIC level though.

#50 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,167 posts
  • HarmlessLion
  • Location:BUR

Posted Wed Jun 26, 2013 11:57 AM

Mini Memory has some commands in TI Basic to save and load from the 4K RAM on the cartridge. How did they do that? Is a DSR being used or is that a GPL solution?


It's a GROM DSR.. TI BASIC, Editor/Assembler... anything written in GPL can usually pull DSRs from both ROM and GROM. Most assembly language programs only check ROM DSRs, though.

You can't use ROM DSRs on the cartridge port, unfortunately.





Also tagged with one or more of these keywords: F18A

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users