StrangeCart

[speccery]

I want to continue the integration of the StrangeCart to the normal TI infrastructure, so I wrote today my very first few instructions in GPL! My intention is to enable saving of TI Basic programs into the Flash memory of the StrangeCart. I took the code base of the Mini Memory as the basis, and added to the code an small extension, which doesn't do much yet. I just created the start of a DSR of a new device "SCMEM". It is now possible to write in TI Basic:

SAVE SCMEM.HELLO

The GPL code I created writes the string SCMEM.HELLO to the address >7012, its length to >7010 and it also saves the first 128 bytes of the Basic program to >7080. The ARM could take that and write it to the serial flash memory, but it doesn't do that yet. But by dumping the memory of the ARM I saw that the data arrived in the RAM of the ARM as expected. Not a big deal, since emulating the mini memory already supported RAM for the TI. Going from here to supporting saving should be simple, now that this data transfer works.

 

The mini memory source code is in my opinion a great starting point for looking at GPL.

 

I used the StrangeCart (obviously) for developing the GPL. I have to say that it is very convenient to be able to easily upload with XMODEM a new version of the GPL code into the StrangeCart. No need to unplug or power cycle anything, just a simple USB connection is needed.

[+9640News]

Not knowing where you fully intend to take the DSR, but if you have intentions of it being accessible as a disk i/o type device, you might want to use a 3 letter and 1 digit device name.  This would more likely keep you compatible with a host of other disk manager type programs and utilities.

 

Just something to think about.

[speccery]

2 hours ago, 9640News said:

Not knowing where you fully intend to take the DSR, but if you have intentions of it being accessible as a disk i/o type device, you might want to use a 3 letter and 1 digit device name.  This would more likely keep you compatible with a host of other disk manager type programs and utilities.

 

Just something to think about.

Thanks, good idea. Changing the device name is very easy.
I’m not planning to take the idea far, but I want to play a bit with the idea of the cartridge being a “super mini memory”. I think it’s a nice test bed for software integration. GPL DSRs are not scanned and found by all software, but TI Basic does do it. I’m not sure what is the support for cartridge space machine code DSRs, I guess DSRs in cartridges are rare.

[+OLD CS1]

New contest: come up with a three-letter name for the StrangeCart DSR.

[+Lee Stewart]

4 hours ago, speccery said:

I’m not sure what is the support for cartridge space machine code DSRs, I guess DSRs in cartridges are rare.

 

Pretty sure that is impossible without a GROM boost. The only DSRs in CPU space are at >4000 – >5FFF.

 

...lee

[RXB]

6 hours ago, OLD CS1 said:

New contest: come up with a three-letter name for the StrangeCart DSR.

SCD = Strange Cart Dsr

or Strange Cart Device

[+OLD CS1]

3 hours ago, Lee Stewart said:

 

Pretty sure that is impossible without a GROM boost. The only DSRs in CPU space are at >4000 – >5FFF.

Where do MiniMemory's MINIMEM and EXPMEM2 DSRs live?

[wierd_w]

I would suggest the entirely unoriginal DSR1, DSR2, etc...  Simply because they are very self explanitory what they are, and nobody else has done it.

 

It also avoids abbreviating it "SCT" , "CRT", or "SCD".

[HOME AUTOMATION]

1 hour ago, OLD CS1 said:

Where do MiniMemory's MINIMEM and EXPMEM2 DSRs live?

Not to mention... EXPMEM1.

 

My favorite is TERMINAL EMULATOR II's... "SPEECH"!

[speccery]

34 minutes ago, OLD CS1 said:

Where do MiniMemory's MINIMEM and EXPMEM2 DSRs live?

They are GPL routines, so >6000 in GROM space. That's what I did so far too.

[Tursi]

37 minutes ago, OLD CS1 said:

Where do MiniMemory's MINIMEM and EXPMEM2 DSRs live?

GROM... the only way to do a DSR from the cart port is via GROM, because of missing address lines it's not possible to know when there is a CPU access to >4000, even if the console hasn't removed the CRU lines.

 

[+OLD CS1]

48 minutes ago, wierd_w said:

It also avoids abbreviating it "SCT" , "CRT", or "SCD".

I kinda like "OCD".

 

@HOME AUTOMATION Oh, yeah, I forgot about EXPMEM1.

[HOME AUTOMATION]

1 hour ago, OLD CS1 said:

Oh, yeah, I forgot about EXPMEM1.

HaHa! I forgot about "ALPHON".

 

As for EXPMEM1, TI, apparently chose not to mention it!

[RXB]

3 hours ago, wierd_w said:

I would suggest the entirely unoriginal DSR1, DSR2, etc...  Simply because they are very self explanitory what they are, and nobody else has done it.

 

It also avoids abbreviating it "SCT" , "CRT", or "SCD".

Why? We have SCS for SCSI, WDS for Winchester Disk Drive and IDE for IDE drives along with HDR for Ramdisks.

[+jedimatt42]

If it doesn't implement level 2 io like direct block read or sector io or rename, then there is no need for the three letter + unit number naming convention. 

 

Existing LVL2 using software won't work with a new name anyway.. without being updated to know how to map the subroutine names. 

 

If you don't have those needs, then you can use up to 7 characters for the device name.

 

"STRANGE" would actually work. My personal belief is: let people use old drives for old software. 

[+jedimatt42]

Also, most disk based software that access additional files use DSRLNK that does NOT look at GROM DSR entries... 

 

So requests for compatibility with some unspecified set of software is myth based.

[RXB]

41 minutes ago, jedimatt42 said:

Also, most disk based software that access additional files use DSRLNK that does NOT look at GROM DSR entries... 

 

So requests for compatibility with some unspecified set of software is myth based.

It is not that hard to use the Miller Graphic GPL LINK DSR that has been cut down and works for everything.

You suggest using hamstringed DSR that makes little sense to use.

 

Why drive a 4 wheel drive when you can ride a tricycle, yea you still get there on three wheels but there is no advantage to doing that.

 

Also what MYTH BASED device are you talking about? We have a myth based device that was made or exists?

[+jedimatt42]

Correct. 

 

But most existing software doesn't, because the example from Texas Instruments didn't. 

 

So depending on the software target for this feature, worrying about the device name may be entirely pointless.

[RXB]

1 hour ago, jedimatt42 said:

Correct. 

 

But most existing software doesn't, because the example from Texas Instruments didn't. 

 

So depending on the software target for this feature, worrying about the device name may be entirely pointless.

So screw improvements?

Hmm you came out with TIPI so that means zero improvements from now on?

Sorry I am pretty sure your logic failed here!

[RXB]

I guess another way to look at this is like I have said to Conservatives my whole life:

 

Hey why do you throw the Virgin into the Volcano even today and you know it does not work.

Conservatives: We have always done it as it is a tradition.

 

Another example:

Just because the VW Bug was the most popular car on Earth never once meant it was the best car ever made.

It means it was POPULAR not the best.

 

Another example:

In the HURT REPORT from a motorcycle magazine. "No one is fascinated with a Crescent Wrench as people dearly love to complicate things."

 

I think the best way to design software or hardware is be as up to date as possible and advance the design, I do not believe old ways are best.

 

[+9640News]

The most versatile disk manager I have seen is DM2K. It would also be the most likely candidate for an update to add capability with something that may be accessed a bit differently.

 

[+OLD CS1]

@RXB All well and good, but then following "tradition" when there are arguable reason for doing so is no vice.  As @jedimatt42 pointed out, if the DSR will not offer lvl2 functionality, then there is indeed no reason to stick with a three-letter device name and your perspective wins the day.  Otherwise, since there is a ton of software out there already which may rely upon three-letter device names, then sticking to tradition, as you say, is not doing so just for tradition's sake but rather for predictable good outcomes.

 

So, bottom line, three-letter for some purpose, up to seven letters for another.

[+jedimatt42]

I feel my post stand well as written.

 

My intention is to promote improvement and innovation by only burdening ourselves with tradition when truly applicable. 

 

 

[RXB]

1 hour ago, OLD CS1 said:

@RXB All well and good, but then following "tradition" when there are arguable reason for doing so is no vice.  As @jedimatt42 pointed out, if the DSR will not offer lvl2 functionality, then there is indeed no reason to stick with a three-letter device name and your perspective wins the day.  Otherwise, since there is a ton of software out there already which may rely upon three-letter device names, then sticking to tradition, as you say, is not doing so just for tradition's sake but rather for predictable good outcomes.

 

So, bottom line, three-letter for some purpose, up to seven letters for another.

How much backwards compatible software expects 3 letter names for Devices?

I do not view standards as Traditional as you can expand backwards compatibly forward.

So what device has a 7 letter name?

 

And I am guilty of assuming all names are 3 letters. i.e. SCS#, IDE#, WDS#, DSK#, HRD#, ESD# just to name a few.

[+OLD CS1]

27 minutes ago, RXB said:

I do not view standards as Traditional as you can expand backwards compatibly forward.

You made the explicit comparison.

27 minutes ago, RXB said:

So what device has a 7 letter name?

MINIMEM, EXPMEM1, EXPMEM2, for instance. Then there is RS232, ALPHON, SPEECH, CLOCK, &c., not seven letters but more than three.