jedimatt42

Jim makes available pcbs for a variety of EPROMs... I think the 'black' boards are typically 64k, and the 'red' boards are typically 512k, but some jumpers allow switching... The thing to do, is build your ROM to the smallest of 32k, 64k, 128k, that you need, and let the user making a physical cartridge replicate the data to fill out the size of EPROM they are using... So, if you make a 32k rom, and we stick it in a 64k EPROM, we would load the EPROM with 2 copies of your 32k rom.

Jim was saying in practice that the latches either power up to all zero bits, or power up to all 1 bits. So in practice, he suggests you could get away with the first and the last bank. But since that power up state is not a promise from the chip manufactures, in practice I ( and I believe all the bank switched ROM only carts I've seen ) put the header in all banks.

It is available now. Updates are available based on the data in this file, on this branch of the github repository: https://github.com/jedimatt42/tipi/blob/bullseye_release/version.txt

Not sector support, but direct-input and direct-output support will be added, to clarify.

My automation to mirror from my internal gitlab to public GitHub seems to have broken. I'll fix it tonight. (turned out to be an IP address error)

On the pandemic club zoom call yesterday, we realized more needs to be done to fullfil the user case. That is direct-input and direct-output support for VARIABLE record files, to enable copying to and from ramdisks.

Update 3.10 - April 23rd 2023 - fix NATIVE_TEXT_DIRS to not strip the leading 'TIPI.' off the path IF you actually have a directory in your 'TIPI.' drive named 'TIPI'

Ok, so you must have a directory named TIPI on your drive named TIPI ... so it strips the TIPI. off, and then added the '.' back, and ended up referencing the entire drive...

Oops, that is a bug in my adding a trailing '.' without first checking if the setting is empty. Sorry about that. For now, just delete the line from the /home/tipi/tipi.config file on the Linux side. ---- A side note, updates don't generally benefit or require rebooting the PI. The update process automatically restarts the services.

Seems like your emulation page needs to be aware of some of this info: and:

As @senior_falcon references adding 1 bank of GROM, I would infer that this thread has nothing to do with XB ROMs. The trick to having a header in each bank, and not corrupting the data that wants to be copied, is to not assume that the data is squarely in a ROM bank, but that you are copying segments with a begin and end, into an address, much like an EA5... but, yes, it is more complicated. If you want this for free, you can just write an EA5 program and then in the classic99 debug menu, there are tools for dumping memory into a cartridge binary. It'll interview make the cartridge and menu entry and give you the ROM to RAM copier all for free. Fred Kaal also has a module creator tool. Both will pack things in efficiently, and if you are not using all 8k of the lower ram expansion, it'll likely pack to a single 32k ROM. If it can be just ROM, then making real cartridges is far cheaper. If you include a GROM, then FinalGROM99 or UberGROM become the minimum requirements for real hardware.

Yes, on real hardware with 74'379, 74'378 or 74'377 latches for the bank address, they do not have a deterministic or specified starting value for the latch data. So it is effectively random on power up. Some chips are consistent, but a different physical chip makes no promise to agree with any other physical chip. This includes uber-grom ROM only boards. There was some nuance here, which I do recall, but it is inconsequential for practical application. I believe the FlashROM99 was still nondeterministic. I believe the FinalGROM99 was deterministic. But for community sake, that detail is best ignored.

Update 3.9 - April 22nd 2023 - add PI.CONFIG option: NATIVE_TEXT_DIRS, which allows setting a list of directories that automatically apply the ?W flag to save files within as native text files instead of TIFILES. - update PI.CONFIG to allow opening in VARIABLE 256 record length, so you can set longer values for NATIVE_TEXT_DIRS and other things, like the URI1 mappings for instance. - when reading PI.CONFIG, if the record is longer than your specified record length, then the read record will be truncated. - 80 character records is still the default if not otherwise specified when the PI.CONFIG file is opened. wiki docs are updated - https://github.com/jedimatt42/tipi/wiki/PI.CONFIG#native-text-directories

Ah, it looks like PI.CONFIG enforces a limit of 80 columns, and it doesn't know anything about wrapping.. that's not compatible with my mental model... I will fix it so you can open it with longer record lengths to set longer values... but that will still limit you to a 254 character record. I'm curious, I've never heard of anything where an '_' indicates line continuation... what platform/system/software does that?

My communication style failed. Anyway, for the Geneve userbase's ears, the PI side of TIPI does not know anything about TIP1. So settings in PI.CONFIG, or raw file access over messaging that I have recently documented, all have to pretend to be a 4A.

3.x was a full operating system update and a bit of a leap forward on the Linux kernel via the upstream Raspberry PI OS. I can only guess they've changed things such that slow SD cards fall back to SPI or something horrible like that. And it has been 18 months since Raspberry PI OS transitioned form 'buster' to 'bullseye' so there have been more upstream changes than I have time to understand. SD cards also degrade in write performance over time. My 4GB card I use to create the master image I share is a class-4. I'll look into how it performs.

I'll be working on this, this weekend. I'm thinking, set PI.CONFIG by writing a line like: NATIVE_TEXT_DIRS=TIPI.SOURCE.GIT.,TIPI.EBOOKS.,etc Where the value of NATIVE_TEXT_DIRS is a comma separated list (if you only need one directory, use no comma) and if the device name (drive, directories, and filename) being opened on the 4A is prefixed by one of those directory entries, then the ?W native file flag will be applied. This means it will be applied to any file in the listed directory, including descendant directories... Hmmm... you guys in this thread use TIP1 instead of TIPI for the device name... that's just... I know there were reasons... So, I'll amend this example... to reduce your our cognitive load. NATIVE_TEXT_DIRS=SOURCE.GIT.,EBOOKS.,etc You will be able to omit the TIPI. part, it will be implicit, you can include it though if you like... I will also add a trailing directory separator '.' if it isn't provided. The implementation will resolve to real Linux paths before checking the descendancy... so drive mappings like DSK1-4 will also work. But the setting should, as shown, be in 4A style directories. There will not be any escaping logic for directories that have a comma in their name from the 4A perspective... Any explicit native file handling flags specified in the operation device name will take precedence over the directory implying the ?W flag. Let me know, if any of that sounds off target...

Oh, I was wrong... it's a 64k limit... the length of the message containing the devicename is 16bit.

Here my friend, I have documented the direct messaging workflow of each 4A level 3 device service routine in the TIPI ROM. https://github.com/jedimatt42/tipi/wiki/PABMessaging With this you should be able to circumvent your OS quirks. There is a note in there, that the way the device-name is messaged allows you to exceed the device-name limits of the PAB system. So you could send a 2 megabyte 64k URL if you want. I have documented this, so I'll try not to break it in the future.

4A device/file name strings for an OPEN DSR call can be 255 characters long. URLs can be longer than many 4A programs can support, so I created the URI1, URI2, URI3 mappings. A program that needs to create a long URL for use with PI.HTTP or PI.HTTPS file system access should first write the mapping to PI.CONFIG for URI1, URI2 or URI3. Those mappings were never meant for manual configuration except to test. Programs should set them without regard for manual settings users have misused. The ?J modifier should still work for the URI1, URI2 or URI3 as URI1.?J.some-additional-uri-path-or-http-query-params, for example. This should allow for close to 500 character URL usage. File IO does run through the TIPI messaging system, but that isn't documented outside the TIPI DSR ROM code.

Yep, Falcor4 asked me for the dimensions, so I figured the best way to communicate them was through a model. I'd be curious if you tried exporting again, if the dialog shows 'units' as 'Millimeters' now? I found a spot to set that as a property on the 'part'. The dialog always shows me millimeters, cause that is in my account preferences... So maybe I've been mis-educated.

Update 3.8 - April 15th 2023 - still - Updated WEB UI emulation page to include note about running js99er.net from the 'http:' not 'https:' url for use with the websocket. Added link, and note that some web browsers auto-promote to https: if they can (this was biting me today, most frustrating). - Updated #? wildcarding in 2 ways: - when used for the part of a path that is a directory, then it will only match a directory - when used by a LOAD operations ( OLD, or EA5, or Adventure, TOD, TI-Artist, you know, things consuming PROGRAM image files. ), then it only matches files that are PROGRAM images, or follow the rules for TIPI to auto-convert to a BASIC PROGRAM image file. So, in practice OLD DSK1.#? will load the first PROGRAM image in whatever directory you have mapped DSK1. to even if there are files like !README that are DV80s that are alphabetically first. Note, remember how EA5 loaders work when there are multiple files? Sure you do... the loader ( tms9900 software ) has to increment the last character in the file name, and then attempt to LOAD that. That doesn't work well with using the #? at the end of the name... But if you are using the #? to just be lazy, make that little extra effort to add the last letter of the file you want... if you have PACMAN and PACMAM that need to load, then you can specify #?N and an EA5 loader will be able to increment the N to the M, and then TIPI will be able to match the #?M to that second file 'PACMAM'

I call one of the routines here for the builtin float to int: https://github.com/jedimatt42/fcmd/blob/a4e2ad136eb0d3b2d33b67e644d8ac3417becc94/b2_tifloat.c#L55 The input parameter was the address of the TI float data. The address of the routines can be found in the TI Intern. For the float to int, there was no benefit in using the XMLLNK overhead. I did not examine the other routines. I've had no use for actual floats. Float arithmetic is a choice, and usually sub-optimal unless you need to show a result as a float.

Update 3.7 - April 15th 2023 - I broke something in the JSON stuff... I fixed it now. Just update.

Oh, the hugeness issue is because your units in onshape are not setup before you exported. It's a global setting for the user, not the model... I forgot about that step. I guess I should export the STLs myself and share them indirectly.