Who uses the ROM Font/Log/Sine tables in the Propeller? Other ideas for ROM usa

Cluso99

Postedit: I changed the subject to include the Log/AntiLog and Sine Tables. See my post below for further questions.

Apart from VGA demos using the Rom font, I am not aware of anyone using it.

Does anyone use it?

It uses half (16KB) of the hub ROM. I was wondering if it could be used for other things such as...

• A smaller 256 x 8x8 font (2KB), perhaps an inverse version (2KB), and a widget font (2KB) too.
• Booting from SD card (say on pins P24..27)
• An additional·Interpreter (without risking the old interpreter in case of bugs)
  • Faster using my decode version
  • LMM extensions
  • optional extensibility to hub ram
• FAT16/32 SD card routines
• Some generic out routines (to expand things like str, hex, dec, bin)
• Cog objects for...
  • Low level SD driver
  • A version of FullDuplexSerial
• Overlay loading???
• Floating point???
• Some form of PropBasic for SX emulation???

What do you think?

Are there any other things that could be more useful?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Post Edited (Cluso99) : 7/3/2010 4:25:02 AM GMT

Phil Pilgrim (PhiPi)

I use it all the time. It's a very nicely-rendered font and an essential part of TV_text and my own TV_wtext, as well as my OSD stuff for the Backpack. It's a vital component of the ROM. I can't imagine doing without it.

To answer your question, no, there isn't anything that could be more useful in its place.

-Phil

Mike Green

I use it with TV_Text and TV_WText. I also have my own version of the TV_Text driver with its screen buffer in the cog. All of them use the ROM font.

ElectricAye

I use it for my VGA outputs. Yes, it's convenient to have the nifty symbols sometimes and the hieroglyphics helps complete the dark, alchemical ambience I like to generate with my experiments.

Cluso99

Thanks guys. Dam. I thought I had found a place for some code improvements [noparse]:([/noparse]

Postedit: However, I am still interested to persue this option for other purposes and ideas. For starters, the miniprop version would not use it, so there maybe some advantages in discussing what could be in here. It could also serve for some ideas of what could be put into Prop II's ROM which is much bigger.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Post Edited (Cluso99) : 7/2/2010 4:19:26 AM GMT

Phil Pilgrim (PhiPi)

I wouldn't rule out the font for the miniProp, either. Even with two cogs, there's still a possibility -- albeit with tricky coding -- to do video and still have a source of data to display.

-Phil

smbaker

Somewhat loosely related ... I was looking at the font in the propeller manual, and noticed it has a set of schematic symbols (resistors, gates, diodes, capacitors, etc). Has anyone found a use for those symbols? At first it seems like a unique and interesting feature, but on second thought the applications seem pretty limited.

Back to the OP, one option would be to compromise and throw away approximately half of the font space in favor of something more useful. 90% of the applications probably use only 50% of the font. The internationalization in particular could be optimized. Note that there are 6 versions of upper case "A", six versions of lower case "a", etc., with only minor differences (maybe 4-6 scanlines differ?). It would certainly complicate the video driver though.

SSteve

smbaker said...
Note that there are 6 versions of upper case "A", six versions of lower case "a", etc., with only minor differences (maybe 4-6 scanlines differ?).

If you spoke a language that used those letters, they wouldn't be six versions of lower case "a". They would be six different letters. For example, alphabetized Norwegian puts the letter

Phil Pilgrim (PhiPi)

The schematic characters are used mostly for documenting Spin files. I've never used them, or seen them used, in an actual video application; and I doubt they'd be missed. However, some of the upper-ASCII European characters certainly would be missed if they were absent.

Come to think of it, though, the "wiring" characters are used for drawing boxes, so they'd need to be kept as well.

-Phil

Tubular

Amongst W9GFO's excellent photo stream was a pic of the "FIB - Focussed Ion Beam" that can (presumably) post-edit the silicon

Could this be used to tweak an individual prop chip, eg adding a serial number, "hobbling" an instruction or instruction decode, or (somewhat less seriously) add serifs to the existing font?

modelstation.smugmug.com/Events/UPEW-2010/12744525_m6VUt#917978692_suCDj-A-LB

smbaker

SSteve said...
If you spoke a language that used those letters, they wouldn't be six versions of lower case "a". They would be six different letters. For example, alphabetized Norwegian puts the letter

potatohead

I would keep that font in the ROM, and add an 8x8 one, color interleaved like the Parallax one is, with a similar set of characters, dot reduced to work in the 8x8 frame. That's a 4Kb font that can easily be rendered 2 color, seperating the characters in the video loop on Prop II, if need be.

Having both fonts in ROM is often a significant memory savings. Put me on record right now, if there is a chance at getting a nice 8x8 in the ROM, encoded this way, I'll spend the time to author it [noparse]:)[/noparse]

On higher resolution displays, the ROM font is really great, and it maps perfectly to the "reference" waitvid functionality. IMHO, given the objects out there, it's a must have.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

RinksCustoms

pardon for the ignorance here, but doesn't ROM stand for read ONLY memory, ie- its etched into the silicon and cant be changed?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! So easy a caveman could do it...
http://folding.stanford.edu/ - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.

heater

RinksCustoms: Presumably with some suitable probe one could chop tracks on the silicon like you can on a PCB or blow the diodes that make up the ROM. (Do they do it like that on chips). I do recall Cip describing how he did that to get the first Prop silicon working. Perhaps only being able to turn zeros into ones or vice versa but not both ways around.

So, could be a way to code useful info into Props. The price would be enormous.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99

The ROM code is a mask, so when it is generated the appropriate code is hardwired, and all the silicon from this is fixed. However, ROM code changes can be done with less cost than a whole chip.

If there is a new mask being done for Prop 1.5 then the ROM code could vary from the current ROM. However, it is the same size, so no gains here. Something would have to give and hence my question.

If there is a chance for a smaller (say 2 cog version) prop, then I would think the current font would be useless as there just would not be enough horsepower and cogs. However, an 8x8 font for a single TV cog may be usable. There could be a lot of other extra code placed here instead of the 16KB 16x32 font now in the Prop's ROM. In particular, something to entice the SX users over. Also the possibility of not requiring an eeprom for this.

Of course the last purpose is to see what others would like in the Prop II as it has more ROM. I would think this has not been frozen yet. Note this is just a guess.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

RinksCustoms

agree do i about the rom being of more versatility if it were more like EEPROM/NVRAM.. as far as the prop 1.5, unless they impliment port B making those chips are pointless as discussed in another thread about the prop 1.5 and prop II. I would think if the prop II comming out wants a fighting chance in the market, perhaps HDMI could be implimented some how, but i dont think that is within the capabilities of the next prop, at least i havent come across any mention of it. The reason i say this is the fact that finding displays that support composite video, s-video, or analog broadcast are going to become rarer as the years pass. True, Legacy VGA is still and probably will always be supported by todays monitors, which actually gives better performance than composite/broadcast, and im not exactly educated on the HDMI specs for broadcast signals, but im sure the two aren't compatable or you wouldn't need a pricy add-on tuner box adapter for an analog TV.
·But enough rambling, Im not sure what the current rom holds, and maybe usb, BT, I2C interfaces could be implimented instead of bit-banged drivers (which work well). Font in the rom is supposed to save ram, no? and if its one big factor on the die of the new chip, its ram that suffers isnt it? Would moving the rom font into one of the COG's be more usefull? how many displays are you going to be able/want to drive with the prop II? RAM despite 64 I/O channels, i think would be more at a premium than anything.
·From an economic standpoint rev B/1.5 doesnt make much economic sense to even produce with 4 cogs, your not saving any power, just loosing capability, unless your gaining CLOCK, RAM and Port B and only to replace rev A. By now everyone here pretty much knows the capabilities of the prop, its prowess, and also its limitations and shortcommings. The Propeller² should be just that, the propeller rev A squared, speed, ram, capabilities, it should also try to reduce the·limitations of the Rev A·if possible, and i think the prop II will be just what the doctor ordered, ..when its unveiled. i know that its always easier said than done, but i think the·guys responsible for·the Rev A couldn't be from this planeta nd also carry the old american "CAN DO!, WILL DO!" attitude.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! So easy a caveman could do it...
http://folding.stanford.edu/ - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.

Kye

I believe almost no one uses the log and anti log tables. Those could be scrapped.

Well, atleast I've never seen anyone use them.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Dr_Acula

Wish list for ROM?

Actually, I never really appreciated there was so much ROM. It seems a pity there is a nifty ROM font, yet the VGA 80x40 driver uses so much precious hub ram just to store a font. Presumably because it is a bit smaller than the font in ROM.

One can dream about all sorts of cool things in ROM.

My general philosophy is that if you want cheap mass storage, an sd card is the medium of choice. Much better than eeprom or eprom. So if you can talk to an sd card, you can load further data off the card.

I'm hooked on Kye's FAT32 code. So simple, so easy and it seems to work with a huge variety of sd cards I have scattered around my study.

So I'd be interested in some minimalistic ROM code that can search for a certain file on an sd card and run that file. BOOT.BIN or whatever. Then you would not need an eeprom if you had an sd card.

One potential challenge though - how do you define what pins to use? Or do you write the code so it tests pins 0-3, then 4-7 etc and works through all the pins looking for an sd card? It would be messy though, as it would add to the boot time for all propeller chips.

Hmm - Futurlec sell those eeprom chips for a very reasonable price. Maybe the existing solution is the best after all?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

Oldbitcollector (Jeff)

smbaker said...
Somewhat loosely related ... I was looking at the font in the propeller manual, and noticed it has a set of schematic symbols (resistors, gates, diodes, capacitors, etc). Has anyone found a use for those symbols? At first it seems like a unique and interesting feature, but on second thought the applications seem pretty limited.

Sounds like a VGA software project just waiting to happen.. I'm picturing something which you could use the mouse
to drag and drop these symbols for prop-schematic creation, then save it as a bitmap. Too many projects this direction,
too little time.. [noparse]:)[/noparse]

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.

Invent-O-Doc

I like the current font, but an 8x8 also would be nice. Many of Cluso's ideas would be great to have in prop-2. Do we know what will be in the propeller 2 ROM?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

---

Tom Talbot
New Market, MD, USA

smbaker

Oldbitcollector said...
Sounds like a VGA software project just waiting to happen.. I'm picturing something which you could use the mouse
to drag and drop these symbols for prop-schematic creation, then save it as a bitmap. Too many projects this direction,
too little time.. [noparse]:)[/noparse]

One interesting little application would be to let the user drag and drop components around, and then have the prop simulate the circuit that was created, using actual pins for IO. Perhaps dip switch inputs on one side and LED outputs on another. Probably somewhat limited on what could be simulated as analog (maybe simple RC oscillators), but digital components could be easily simulated.

I recall back in high school decades ago some large pegboard-looking device that let me plug together gates in some particular order and create a binary counting circuit.

Could do the whole thing one one chip, including VGA out and mouse/keyboard in. Could be an interesting tool for intro EE or CS students.

Cluso99

Potential features of·a NEW ROM code for the Prop...

Existing Prop ROM space:

• Font 256 @ 16x32 (16KB)
• Log/AntiLog (8KB)
• Sine (4KB + 2B)
• Booter & Interpreter (4KB - 2B)

What could fit in if we dropped something such as the Font or Log/AntiLog or Sine ??

Possible New·Features:

• Interpreter
  • Faster spin interpreter (3KB) (could save 2KB if we replace existing interpreter)
  • Extensions for LMM (0.1KB?) (could be 0KB if in the faster interpreter)
  • User extensible in hub (<0.1KB) (could be 0KB if in the faster interpreter)
• Font
  • 256 @ 8x8 (2KB)
  • 256 @ 8x8 inverse (2KB) (if space) (improves TV performance)
  • 256 @ 8x8 widgets (2KB)·(if space)
• Drivers (Cog or Interpreter versions)
  • I2C low level EEPROM driver (0.1KB) (make user accessible from booter code)
  • SD low level SPI driver (1KB)
  • FAT 16/32 basic driver (1KB?)
  • Some form of USB serial device driver ???·(??KB) (P30..P31) (cheap loader/comms to PC·without FTDI chip)
  • Some form of Serial driver such as FDX or PST ??? (2KB) (P30..P31)
• Boot options (some require above drivers)
  • Serial P30..P31 (0KB) (already exists)
  • EEPROM P28..P29 (0KB (already exists)
  • l or EEPROM or SD or USB serial (see requirements next)
  • SD card P24..P27??·(0.1KB) (requires the low level SPI driver and part of the FAT16/32 driver)
  • USB serial ???·(0.1KB) (requires the USB serial device driver)
  • If all the above fails, boot the PropBasic (requires the PropBasic below) or mini C ??? (see below)
• Removes the requirement for EEPROM (0KB) (can use SD, or PropBasic, or mini C·with serial or USB)
• Some form of PropBasic/FemtoBasic (??KB) (upgrade path for SX users)
• Some form of C interpreter ??? (??KB) (something like the·mini C compiler/interpreter for the Palm Pilot)
• Some generic out routines (to expand things like str, hex, dec, bin) (<0.5KB?)

We could fit most of the above (or all?) into 8KB. There are a lot of benefits to get this code into the ROM !!!

So, here are some Questions...

• Could we remove the Log/AntiLog tables ?
  • Who uses them ?
  • Do they have hub space (i.e. RAM) so they could load them there ?
• Could we remove the Sine tables ? (less space here, so could not fit everything proposed in)
  • Who uses them ?
  • Do they have hub space so they could load them here ?
• Could we remove the current font 256 @ 16x32 ? (already asked originally, but here again to be consistent)
  • Who uses them ?
  • Do they have the hub space to load the font here ?
  • Could the font be reduced ? (i.e. are all 256 chars used
• Could this replace the ROM code for Prop 1 ?
• Could this be an alternative ROM code for the existing Prop 1 ? (i.e. keep both versions - not good, but a posssibility)
• Could this be the ROM code for Prop 1.5 ?
• Could this be used on a cut-down Prop (say a 2 cog version) ?

Good discussion here will give Parallax some ideas and possibilities. It is so nice to be able to actually discuss these things with a supplier/designer at this level of openness!·

PS. I have changed the subject.

Are there any ramifications for supplying USB for·non-compliant code ???

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Post Edited (Cluso99) : 7/3/2010 4:28:41 AM GMT

Phil Pilgrim (PhiPi)

Cluso,

Device drivers do not belong in masked ROM. The hardware they're designed for is in constant flux and can become obsolete before the Prop does, and everyone has their own tweaks for these things anyway. I believe that Chip made a highly intelligent choice in his mix of ROM functions: the bare essentials for getting the Prop loaded and running, a cunningly clever and compact Spin byte code interpreter, a nice-looking font that works well with both VGA and interlaced video, and useful math tables that never become obsolete. 'Sorry, man, I don't mean to rain on your parade; but, given the amount of ROM address space available, I just don't see any room for improvement.

And, yes, I've used everything in the masked ROM at least once, and I'm damn glad it was all there.

-Phil

kuroneko

Whatever happened to K.I.S.S.? And if this gets of the ground you better make sure that the 3rd party code works (FWIW, personally I disagree with this whole thing).

smbaker

Cluso99 said...

What could fit in if we dropped something such as the Font or Log/AntiLog or Sine ??

Another way to look at this is what could only be done in ROM. The one key candidate that I see are boot loaders. If ROM had support for booting from an SD card, then the eeprom could be dropped from many designs that are using SD cards. An entire fsrw driver is not necessary; only enough to fetch a few blocks from the SD card into RAM and execute them, which would then bring complete fsrw support online, and then bootstrap an operating system off the SD card.

The rest of the items, while they might be nice, seem entirely optional because they could be placed in eeprom and/or SD card and read into RAM. Keeping them out of ROM provides more flexibility.

There's a good argument for minimalist design, placing as little as possible in ROM and adding more RAM, although I presume the RAM/ROM proportion was chosen for cost effectiveness.

Scott

Sapieha

Hi All.

I think None of You think as Booter from SD/uSD need dedicated pins -- And we have already 4 that pins add to that 4 for SD and we have 8 pins that will not be usable to all possible things as them in Start time of Propeller will need special attention.

For me it is good as it is in ROM with only one missing possibility

---

Possibility to BOOT directly FROM Pasm code with no need to have SPIN header to it.


Regards

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

Phil Pilgrim (PhiPi)

I can't see any advantage to booting directly to PASM code. The Spin stub required to get to PASM is insignficant.

-Phil

Toby Seckshund

The choice of what was in the ROM will never suit everybody's requirements.

One thing that the "This is the Prop, the only Prop" approach has given is the freedom of thousands of variations such as with the AVRs or PICs, as they try to fullfill every variation on every variation.

I just wish it was out in it's "B" format, also.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Why did I think a new, more challenging, job was a good idea ??

Cluso99

I think you are missing my objectives...

I would like to have some options for...

• Enticing the SX users into the prop
  • For this to happen we need a simple Basic in ROM·(if I understand correctly that is what is in the SX)
  • It needs to be cheap, so...
    • EEPROM would be optional
    • SD (microSD) would be optional
    • Serial connection to PC - hence Serial driver
    • USB serial to PC would be nice - hence USB serial driver (to save big cost of FTDI chip)
  • A simple C in ROM would also be of benefit (not done)
• More advanced users
  • Able to boot directly from SD card
    • hence requirement for·low level SD SPI driver
    • hence requirement for simple FAT16/32 functions to locate a boot file
    • This code is simple and already works (a number of people have this working already including myself with minimal code)
  • EEPROM would be optional - reduces cost and possibly frees 2 pins
• Extend the Interpreter and speed it up
  • This can be done safely if the old interpreter remains provided sufficient room
  • LMM extensions (mostly done although various implementations)
• 256 @ 8x8 Font(s) for TV
  • already done
• Reduced cos.
  • No need for an EEPROM for some applications
  • Specifically, if you have an SD card why would you want an EEPROM if you boot from SD?

I think this would also allow development of more code for the upcoming Prop II. Remember, whether you agree or not, Chip wants to place a self-contained system in ROM. Personally, I agree with him.

Sapieha: Yes, the SD requires 4 I/O pins. They could be partially shared with the EEPROM. I cannot see any reson to boot directly to PASM.

I would like to see the SD on pins P24..P27. Why? Because they then do not block the use of the 8 available pins P0..P7. I know this conflicts with the Keyboard and Mouse on current PCBs. However, the way I see it working, the new ROM would still be able to be used with existing pcbs, just without the extra SD boot·option. The only other problem is with programs using whatever is dropped from the ROM. I see the above options as having far more advantages than the loss of a current piece of ROM which is possibly hardly used.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

smbaker

Cluso99 said...

* Enticing the SX users into the prop
* EEPROM would be optional
* SD (microSD) would be optional

I've never programmed an SX, but don't they need some kind of program storage (built-in or external EEPROM, SD, or other)? Regardless, it seems like whatever language interpreter is needed can be downloaded onto the chip the same time the program is. Assuming that is correct, the fact that an interpreter was downloaded could be hidden from the user so he would be unaware that it didn't exist in ROM.

LMM or built-in overlay support would be nice, so that we could easily have more EEPROM or external RAM than we have internal RAM, for fitting larger programs.

Cluso99 said...

I think this would also allow development of more code for the upcoming Prop II. Remember, whether you agree or not, Chip wants to place a self-contained system in ROM. Personally, I agree with him.

While the idea is cool and reminiscent of the computers of my youth, I don't see all that much utility. I see a definite advantage to putting in support for booting off of SD since that eliminates unnecessary EEPROM from designs that already have an SD card. Any kind of self-contained operating system I would want to customize, and to customize it I would need to put parts of it in rewritable nonvolatile storage, which means I end up requiring an EEPROM or SD card anyway, which means I could have put the whole thing on the EEPROM / SD card in the first place.

On the other hand, if ROM is very cheap (so cheap that it could be considered negligible to the cost of the prop II) then it makes sense to put as many drivers and library routines in ROM as possible. Once you have a complete set of library routines, you need only add an editor, compiler, and command prompt to have a self-contained system.

Scott

Tracy Allen

The sine and log tables are used by the floating point routines, for one thing, and I'd hate to see those broken. The log and exponential are essential math for sensors, such as thermistor linearization or calculation of dew point. There would be alternatives, but they would be either slow (direct calculation) or big (replacement table). It would be hard to count the numerous times people have used the sine tables directly in applications.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com