<tabemann>
is it necessary that s" and ." be able to compile in more than 255 characters?
<tp>
tabemann, hey I was just playing with saving data to a flash memory location after a exception was raised ... it corrupted the flash and Mecrisp-Stellaris wouldnt boot
<tabemann>
agh
<tp>
it's understandable I guess
<tabemann>
were you able to reflash the board?
<tabemann>
or was it permabricked?
<tp>
tabemann, I dont know re more than 255 characters but I suspect not
<tp>
no, I was easily able to reflash it. one cant brick flash that has jtag/swd access
<tabemann>
I just ask because for implementation reasons implementing s" and ." is much easier if I implement it using c"
<tabemann>
*them
<tp>
Im pretty sure that mecrisp has a 255 char limit
gabc has left #forth [#forth]
<tabemann>
I bet there's a way to permabrick a flash device that has JTAG/SWD access - repeatedly flash and then erase the flash until the flash itself wears out
<tabemann>
shouldn't be hard to do if you do it in a tight loop
<tabemann>
you don't even need to do it to the full flash, just the part that stores the vectors
<tp>
yeah but thats not technically 'bricking' imho
<tabemann>
I should buy a device just to test how fast I can kill it that way
<tp>
the whole 'bricking' thing came about with the Linksys WRT54G that placed the bootloader in flash
<tp>
but as soon as JTAG was figured out, bricked WRT54's became a thing of the past
<tabemann>
never put the *real* bootloader in flash, or at least flash you can write without intentionally setting a jumper on the board itself
<tp>
tabemann, you can get a device for $0.50 and hardwire it to your discovery board
<tp>
yeah, it was very lame of Linksys
<tabemann>
tp: yeah, I wouldn't sacrifice my DISCOVERY board for that
<tp>
as your disco board has SWD, you can use that to talk to any STM32 device, even hanging off a few wires
<tp>
I do it myself
<tp>
I have a STM32F051 deadbugged here, it runs Mecrisp-Stellaris
<tp>
and it only has a capacitor across it's supply pins, otherwise it's utterly standalone
<tp>
Id say you could expect 10,000 - 1,000,000 rewrites before you get worn out flash cells
<tp>
I have a couple of discoboards here I cant use until I replace the reset switch because the originals are utterly worn out
<tp>
they have been reflashed uncountable times
<tabemann>
but I mean if you flash the vectors in a tight loop
<tp>
i understand
<tabemann>
I wonder if they'll ever come out with more wear-resistant flash
<tabemann>
I know traditional EEPROMs are more wear-resistant than Flash by far
<tabemann>
but hey have far fewer cells and far longer write times
<tabemann>
*they
<tp>
takes about 3 seconds to flash/test/erase a 64KB block so I estimate it would take a minimum of 8 hours in a loop to detect any dead cells
<tabemann>
the DISCO board has 2K blocks
<tabemann>
and 2K is enough to contain the entire vectors
<tp>
and possibly as long as 34 days
<tp>
you have a F4 iirc ?
<tp>
why waste a F4 ?
<tp>
get a stm32f030xx
<tp>
cheap
<tp>
in any event, it's a bit moot because no one does that
<tp>
if you want to recycle bits forever you use ram
<tp>
or core
<tabemann>
I'm on an L4
<tp>
nice
<tabemann>
but I'm not gonna sacrifice my L4 to test this
<tabemann>
I'd get as cheap a board as possible if I were going to sacrifice it for this kind of test
<tp>
I have some L162RD's I bought for $0.90 each :)
<tabemann>
okay, I've gotta head out - bbl
<tabemann>
:D
<tp>
just get a chip, no board needed
<tp>
they have 384kB flash :)
<tabemann>
the problem is that my hands aren't really steady enough for soldering
<tp>
oh
<tp>
well dont buy a Chinese board, theyre full of fakes
<tabemann>
I won't
<tabemann>
but I need to go
<tabemann>
see ya later
<tp>
no problemo cua
tabemann has quit [Ping timeout: 268 seconds]
iyzsong has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
tabemann has joined #forth
rdrop-exit has joined #forth
<rdrop-exit>
good morning Forthwrights c[]
<tp>
good afternoon Zen Forth Guru!
<rdrop-exit>
hi Master Forth Technician (tm)!
<tp>
as I was programming earlier, I was rediscovering just how EASY it is to write Forth code for embedded, and briefly I felt sorry for coders having to fight all kinds of "HLL" to get the same things done
<tp>
nowdays as my Words get bigger I find I'm splitting off parts into other Words automatically
<tp>
it's just SO EASY!
<proteusguy>
tp, true that. especially now that these embedded devices have enough memory that you can run a repl against them directly and don't even necessarily require a meta-compiler.
<rdrop-exit>
excellent :)
<tp>
proteusguy, I was working on my STM32F1x 'diagnostics' program menu that a C coder is already calling "fancy"
<proteusguy>
tp, I prefer the term "expressive" but yeah - I can guess what he means. ;-)
<tp>
yet it couldnt be simpler in Forth
<proteusguy>
C, properly used, is simply a platform-independent assembly language with an unfortunately expensive call model. Why would anyone expect more from it?
<rdrop-exit>
proteusguy, if your target doesn't have the memory for a resident outer interpreter just use a tether
<proteusguy>
rdrop-exit, yes indeed - it's still less effort than C in that regard.
<tp>
The C coders solution is to make decisions in his binary and then push the results into a USB config string to read it
<proteusguy>
I'm actually curious about people's experiences with tethers and meta compilers. I've ALWAYS had a repl of sorts in my environments. With ActorForth, however, the Ethereum target ultimately has to be a compiled binary of sorts. I've got ideas on how to go about doing this but I figure I should study up on best practices first. Anyone have any insights on techniques or docs for this? Especially for metacompilers because I
<proteusguy>
anticipate having several such targets eventually.
<tp>
in this case most of the users are Arduino users, so they are quite clueless, have a usb connection and a serial terminal so they can flash my binary and connect to repl easily
<rdrop-exit>
tp is a generous soul always making life easy for Arduino-philes
<tp>
proteusguy, rdrop-exit and I are great tether and repl antagonishs here, we debate these issues a lot
<proteusguy>
For Arduino I actually prefer the Atmel ASM over using C.
<tp>
proteusguy, I agree with rdrop-exit that a tether is the most efficient and versatile embedded Forth system
<proteusguy>
tp, right - so I have my forth dictionary built up with primitives and forth words - what's the best way to then migrate a compiled version of just the bits that are needed for my "main" forth word so I have an executable on a target platform with a different CPU?
<tp>
proteusguy, I use mecrisp-across, which is tethered for MSP430 and I use Mecrisp-Stellaris which is a full on chip Forth that needs about 20kB resident flash
<tp>
proteusguy, depends on the target, but I'd think that JTAG is the very best way
<proteusguy>
in my case - focus on simplicity of implementation is of primary importance.
<tp>
proteusguy, Mecrisp-Across uses JTAG to control the target, which appears to have a full resident Forth REPL, but actually has ... nothing
<proteusguy>
tp - my issue here is that my host CPU and target CPU are completely different. So my primitives will have to be different and compile over to the target. The mechanism for selecting and building the binary easiest is what I'm looking for.
<tp>
proteusguy, Mecrisp-Across will work with a totally blank target, Ive done that many times
<tp>
proteusguy, it's the same with Mecrisp-Across, the target is MSP430 and the Host is Cortex-M4
<proteusguy>
tp, right - that's why this solution doesn't completely work for me.
<proteusguy>
oh wait - MSP430 is not ARM?
<tp>
proteusguy, in the case of Mecrisp-Across, the MSP430 'compiler' is written in Forth
<proteusguy>
or it's a different ARM?
<tp>
it's totally NOT arm
<proteusguy>
gotcha - ok so is a similar situation then.
<tp>
utterly different ISA
<tp>
yeah, same situation
<proteusguy>
what's the process of identifying the target and causing the recompilation to occur? just a few forth words?
<tp>
proteusguy, and as a Across user, it's like magic, very slick
<rdrop-exit>
proteusguy, you can interactively lay down words on the target from the host
<proteusguy>
how?
<tp>
proteusguy, it doesnt identify the target to my knowledge, it just expects a MSP430
<rdrop-exit>
via the tether
<proteusguy>
I know what it does - at a fairly high level. My question here is implementation details. How do I build that capability into ActorForth?
<proteusguy>
user guide or dev guide? I'm in need of dev guide stuff.
<tp>
proteusguy, there is no dev guide other than the source which is German
<tp>
it's all GPL
<tp>
I have modified it a lot quite easily and improved my scant German at the same time
<tp>
one thing I love about Mecrisp-Across is that a 2kB flash MSP430 appears to have 64kB Flash for it's dictionary
<proteusguy>
right - I'm trying to find "best practices" details/docs on how to build such a cross compiler. I have some old 8-bit stuff from Brad Rodreguiz (sp?) but am curious if the "science" has been advanced since then.
<rdrop-exit>
It's become easier in some ways
<rdrop-exit>
The traditional tethered setup had a PC Forth with a serial cable that talked to a debug monitor of some sort on the target
<tp>
proteusguy, Mecrisp-Across is quite advanced I feel, because it does a lot of optimisation. For instance it produces better assembly than I can!
<proteusguy>
tp, I saw that in the docs.... "* Constant folding
<proteusguy>
* Register allocation for both data and return stack
<proteusguy>
* Register allocation across control structures
<proteusguy>
* Dead code elimination (imagine a constant feed into case)
<proteusguy>
* Determination which definitions are in use,just as Freepascals Smartlinking (fpc -XX)
<proteusguy>
* Automatic inlining of definitions used one time only
<proteusguy>
* Interrupt handler framing depending on register usage"
<tp>
rdrop-exit, as in Riscy-Pygness
<MrMobius>
proteusguy, what are your two systems your working with?
<proteusguy>
I'm probably gonna have to skip most of that.
<rdrop-exit>
the debug monitor was either the usual one for that target, or a you made a custom one
<proteusguy>
Initial host environment is Python. Target environment is Ethereum EVM (basic single stack machine).
<MrMobius>
nice
<rdrop-exit>
Today many chips come with a standardized debug interface so you can just talk to that, no monitor required
<tp>
proteusguy, and that claim is very accurate, for instance the best MSP430 'blinky' I could make in assembly was about 80 bytes, but Mecrisp-Across does it in 20 using my very pedestrian Forth 'blinky' source!
<rdrop-exit>
So you end up with a Forth on the PC that places code on the target via the debug interface
<tp>
I think Mecrisp-Across is kinda clever because the first Forth the Author wrote was 'Mecrisp' for MSP430 which is a 11kB resident Forth. He then ported that to Cortex-M and later used a fast Cortex-M4 as the host for his tethered MSP430 Forth
<rdrop-exit>
You can limit yourself to just placing machine code on the target, or build up a headless Forth (without outer interpreter), or a full blown redident Forth
<rdrop-exit>
If you go headless, the headers are kept on your PC Forth
<rdrop-exit>
So in summary, the PC Forth acts serves as a cross-assembling/compiling IDE which you use to build up a target binary or target headless Forth, or target full blown resident Forth, whatever you need for the project in question
<tp>
exactly
<tp>
and these days the target debug interface is the way to go
<rdrop-exit>
The PC Forth can be on a completely different architecture from the target and use a different thereading model to whatever Forth you place on the target
<rdrop-exit>
* threading
<rdrop-exit>
For very small projects you might not even put a Forth on the target, and just cross-assemble something
<tp>
and MSP430 qualifies as very small in many cases with only 2kB of flash
<rdrop-exit>
Basically you are splitting the normal functionalities of a Forth between two systems
<rdrop-exit>
You're host can be as fat as you like, you're target can be as skinny or fat as you need
<tp>
sadly my host is limited to 64kB of dictionary
<rdrop-exit>
as dictated by the project requirements
<tp>
(by the Mecrisp-Across design)
<rdrop-exit>
My host is POSIX based
<tp>
I do recommend that the host have tons of resources
<rdrop-exit>
I'm starting work on RISC-V as my next target
<tp>
because it's fantastic to have all the development resources one may ever need
<rdrop-exit>
proteusbuy, does that answer your question?
<rdrop-exit>
* proteusguy
<rdrop-exit>
I will finally get a chance to write some Forth code today, after a two week hiatus
<rdrop-exit>
I guess he had to step out
<tp>
some code!
<tp>
I've been having a excellent post xmas code writing session :)
<tp>
I'm up to 116 downloads of my Forth 'diagnostics' binary
<rdrop-exit>
I've been distracted by other things, coding is a spare time activity
<proteusguy>
rdrop-exit, yes thanks. I'm really looking at techniques of how best to build the actual cross-compiler.
<proteusguy>
like how to organize multiple targets cleanly and generate the code - that kind of stuff.
<rdrop-exit>
Have you read Sargeant's 3-Instruction Forth article?
<proteusguy>
I recall it but I don't recall it being about building a cross compiler - will check it out again.
<tp>
rdrop-exit, it's more of a "3-Instruction Forth" paper I think
<rdrop-exit>
There's also a draft cross-compiling standard written by Elizabeth Rather et al.
<tp>
I have his Riscy Pygness tethered Forth which is more of a prototype
<tp>
Riscy-Pygness uses TCL to do the cross compiling
<tp>
and a resident target binary to talk serial to the host
<tp>
sadly it has a habit of quietly dying during use
<tp>
I rate it as very Alpha quality
<rdrop-exit>
I only played with his much older DOS one for the Motorial 68HC11
<proteusguy>
tp, TCL eh? hmm... sounds like my own ideas might already be well advanced of common usage. haha
<tp>
proteusguy, grab "riscy-pygness" it's well documented and all in english
<tp>
rdrop-exit, Frank loved the HC11 because after a reset the USART was configured automatically to common easily used defaults, no driver needed
<rdrop-exit>
The original Pigmy Forth is mature, while his TCL based one seems alpha
<tp>
rdrop-exit, pygmy was resident tho ?
<proteusguy>
tp, yes those little things mean a lot. I always loved Atmels ASM because most instructions were single cycle and it came up with obviously correct defaults.
<rdrop-exit>
Pigmy was resident on a host, but you could use his 3-Instruction stuff to build another target
<tp>
proteusguy, you can get perfectly correct cycle counts from coretex-M3 onwards as they have a debug cycle counter, same as RISC-V
<rdrop-exit>
Holon Forth also is interesting to look at
<tp>
proteusguy, only cortex-m0 lacks that facility
<proteusguy>
tp, I don't want perfectly correct - I want 1 cycle. ;-) haha
<tp>
proteusguy, aha! then get a FPGA !
<proteusguy>
tp, personally I've always disliked ARM's ISA. It has always felt wrong to me. 6809 and 68k were more my style. Just a personal smell thing I guess.
<rdrop-exit>
You can also look at Forth Inc's SwiftX and MPE's equivalent for ideas
<proteusguy>
tp, I'm definitely going the FPGA route eventually.
gravicappa has joined #forth
<tp>
rdrop-exit, sadly Franks stuff was too buggy for me. Mecrisp-Across has been rock stable, no silent dying etc
<proteusguy>
tp, Mecrisp has definitely done some good stuff.
<tp>
proteusguy, Im a 6800 ISA lover myself, one always remembers ones first true love :)
<tp>
proteusguy, MSP430 is the closest Ive seen to 6800 ISA
<rdrop-exit>
I hated that it was big-endian
<tp>
I like big endian from a reading memory directly viewpoint
<tp>
but I'm a user, not a programmer, technician first, coder second
<tp>
proteusguy, Mecrisp-* done some good stuff for me so far, but Ive also used Riscy-Pygness and Flashforth (PIC)
<rdrop-exit>
I'm trying to find Rather's paper on cross-compiling
<proteusguy>
I've always found big endian more natural but that's probably my very early hardware experience. I've never had an issue with either as a dev.
<rdrop-exit>
little-endian is more useful for Forth
<rdrop-exit>
you can use b@ 16@ 32@ etc... with the same starting address
<proteusguy>
rdrop-exit, I quickly expand to higher order functions so that just becomes invisible.
<rdrop-exit>
invisible doesn't mean free
<tp>
but nothing in life is free :)
<rdrop-exit>
Forth is all about leveraging such freebies
<tp>
cortex-m can use either in any event
<tp>
I may change to big-endian just for fun
<proteusguy>
rdrop-exit, whether the target was big or little endian - my words would be the same so I didn't lose anything either way.
<rdrop-exit>
the ability I just mentioned is free on little-endian but costs on big-endian
<tp>
proteusguy, but Python as the HLL to compile Forth into machine code ?
<tp>
proteusguy, I wonder if Forth is actually the best HLL to use as a cross compiler ?
<tp>
proteusguy, some people use Gforth on a PC as a means of tethered Forth to other targets
<tp>
rdrop-exit, that took a while, was your MAC version of 'recoll' not forthcoming ?
<rdrop-exit>
I misremembered the name
* tp
hates that!
<rdrop-exit>
I don't know if that's the latest version, it's just what Google brought up
<proteusguy>
rdrop-exit, thanks for the article link for Rather. I had not seen this one before.
<rdrop-exit>
my pleasure
<tp>
she has been my hero ever since she supported after I made this claim on CLF "There is no 'compile cycle', I edit and debug and repeat until it's done."
<tp>
supported me
<proteusguy>
haha yes I agree as well.
<rdrop-exit>
cool
<tp>
the C advocates jumped on me of course
pierpal has quit [Ping timeout: 272 seconds]
<tp>
with claims such as "it's called incremental compiling, so the loop is edit, incremental compile, debug, repeat"
<tp>
Elizabeth replied: "Yes, but it's not a visibly distinct step in a "cycle", as it happens instantly (fraction of a second)."
<tp>
shes pretty much the only poster on CLF that is *really* a programming and hardware expert imho
<proteusguy>
yeah I'm afraid all the feedback I get about CLF is negative. I think #forth here is the best place there is as a public pro-forth forum.
jsoft has joined #forth
<rdrop-exit>
SNR tends to be bad everywhere on the internet, at least here everyone's civil
<tp>
proteusguy, agree 100%
<tp>
rdrop-exit, true here, it's a excellent channel
<rdrop-exit>
CLF tends to be heavily ANS oriented
<tp>
proteusguy, sadly most of Usenet is now full of trolls
<tp>
rdrop-exit, and full of PC Forth programmers only concerned with the language
<tp>
( or is that what "heavily ANS oriented" means ?)
<tp>
CLF has almost zero hardware interest
<rdrop-exit>
it means most people there discuss ANS flavored Forth, which for me personally isn't very interesting
<proteusguy>
ANS fails the ruthless elimination of all unjustified complexity rule to me to be a proper "forth".
<rdrop-exit>
Too much abstraction makes the teeth rot
<tp>
hahah
<tp>
#forth does seem to be all about 'real Forth to me
dave0 has quit [Quit: dave's not here]
<tp>
it seems to me that ANS Forths are all the same, but real world Forths are all different...
<rdrop-exit>
I keep up with the Forth subreddit, although much of the discussion there will make your teeth rot as well
<rdrop-exit>
but it's more civil than CLF
<proteusguy>
rdrop-exit, no such thing as "too much" it's a matter of "right abstractions" vs "pointless abstractions".
<proteusguy>
rdrop-exit, I depend on people like you to post links to useful forth reddit articles. ;-)
<rdrop-exit>
there's a lot of premature abstraction, especially coming from the functional programming types
<proteusguy>
yes trying to turn forth into a lambda calculus language is a backwards step.
<rdrop-exit>
they tend to treat the stack as random access
<tp>
Ive noticed that (understandably) new Forth users usually try and turn Forth into whatever they used last
<rdrop-exit>
good point
<tp>
if it was C then the first thing they usually want to know is how to make 'structures' in Forth
<rdrop-exit>
structures, local variables, the C++ crowd look for arrays and objects
<rdrop-exit>
garbage collection
<tp>
in the embedded world it's usually structures because C has no data types for handling bits
<tp>
so it's done with structures in C
<tp>
which leads to some horrific stuff that always makes me roll my eyes
<rdrop-exit>
I've never handled bits via structs in C
<tp>
in a way the C solution is a bit like how the URL was supposed to websites easier to remember than IP numbers, but nowadays a URL like you get from Google can only be remembered by those with a IQ over 190
<tp>
rdrop-exit, it seems pretty standard in embedded C
<rdrop-exit>
I used the fixed-size integer types in C, uint32_t, uint16_t, etc...
<tp>
and the pains they go thru to design them are amazing. Luckily they can hide them in header files where no one ever looks
<tp>
so a C user coming to Forth naturally assumes that Forth needs structures to hable bit manipulation also
<tp>
handle
<rdrop-exit>
really? crazy kids, stdint.h has been around since 99
<tp>
thats like saying "icecream has been around since 99, 1699"
<tp>
which flavor ?
<tp>
there are many stdint.h but this one is mine...
<rdrop-exit>
it standardized in the C99 standard
<rdrop-exit>
* it was
<tp>
one of the problems one often encounters with various embedded compilers is "stdint.h"
<tp>
usually because it only finds the wrong one
<rdrop-exit>
so they find it easier to use structs than to figure out the path to the right header file? Like I said, crazy kids :)
<proteusguy>
rdrop-exit, I love the reaction I get from the haskell/functional zealots when I point out that their "lists" are really just stacks. ;-)
<tp>
i dunno, I find it a crazy mess myself
<tp>
proteusguy, hahah
<proteusguy>
they're always taking the top item off then passing the rest of the "list" to the next function.... goodness.
<rdrop-exit>
they're teeth have already rotted away
<rdrop-exit>
* their
<tp>
oddly Forth makes dealing with bits very easy as there are virtually unlimited methods
<tp>
proteusguy, it's funny how the NIH syndrome is so strong
* tabemann
is one of those haskell/functional zealots :)
<proteusguy>
tp, well I have to say, as a forth advocate, we have the biggest case of NIH that exists - but then we can actually do it so it's not bragging if you can do it!
<tabemann>
but personally I prefer fingertrees over tradtitional haskell lists
<tp>
when I first started trolling a huge Arduino forum, mainly by just mentioning the word 'forth' it caused a frenzy of insulted posters justifying C
<rdrop-exit>
anyone want to borrow my Zippo to light their torches?
<tp>
proteusguy, haha
<tabemann>
(they have so many more advantages, such as being able to access both ends efficiently and being able to traverse them in logarithmic time)
<proteusguy>
tabemann, what's a fingertree? anything like a skip list?
<tp>
tabemann, not to mention that their trammelgates are fully and harmoniously promulgated!
* proteusguy
feels like he's getting trolled... ;-)
<tabemann>
proteusguys: I don't understand how they work, but their only real disadvantage compared to traditional lists is that they're strict not lazy
<tp>
that wont work for me because I'm very lazy!
<proteusguy>
tabemann, well they must have a size cost over regular lists to offer log access.
<tabemann>
proteusguy: yes, they do have a size penalty
<tabemann>
as regular lists are very lightweight
<tabemann>
I should play with haskell again, as it's been a while since I've worked with it
<tabemann>
but I'm too busy hacking on my Cortex-M Forth
<tp>
tabemann, Ive seen Forth people go to Haskell, then come back again
<rdrop-exit>
I think the point was "I don't understand how they work"
<tp>
tabemann, they seemed to get tired of the endless Haskell rules etc
* tp
now has his Forth cortex-m Exceptions under control
<tabemann>
Haskell is restrictive, but in a way that it helps you rather than hurts you
<tabemann>
tp: have you been able to exit a memfault successfully?
<tp>
tabemann, that's what the Politburo used to say also ;-)
<tabemann>
i.e. without a reset?
<tp>
tabemann, there is no exiting a memfault
<tp>
not with cortex-m
<tp>
the exception halts the cpu and only a hard reset can get it runnig again
<tabemann>
I'm annoyed about that, because with hashforth I can gleefully segfault the process, produce a backtrace, and return the user to the prompt to code another day
<tp>
I can at least get a message out before I lock the irq-fault into a loop
<tp>
tabemann, perhaps those extra 2 billion transistors in your Pentium class CPU are a help there ?
<tabemann>
that's probably because you're just BX-ing the return address provided by the fault, resulting in an infinite loop
<tabemann>
or something like that
<tp>
tabemann, will hashforth put your PC into low power mode where it draws only 4 microamperes ?
<tabemann>
well no, it will not
<tabemann>
okay, I should get to bed
<tabemann>
g'night guys
<rdrop-exit>
The low end CPUs of a product line may not be able to recover from all the faults that a high end one could
<rdrop-exit>
goodnight tabemann
<tp>
nighto tabemann
<tp>
yeah, theyre different beasts
tabemann has quit [Remote host closed the connection]
<tp>
I only do small embedded, Im clueless about PC class cpus
<rdrop-exit>
only 1802 for you
<tp>
well Im clueless about everything, slightly less clueless about embedded
<tp>
haha, I had a RCA CDP1802 but never used it
<tp>
it was too wierd for me after the 6800
<tp>
the 6800 was as American as eating apple pie and cream after church
<tp>
the 1802 was like hanging out in some dark corner with dudes in overcoats and hats
<rdrop-exit>
1802 would be fun to play with in a code golf kinda way
<tp>
i never even used my Signetics 2650
<tp>
the 6800 left me as content as a human could be, I wanted nothing else
<tp>
it was love at first byte
<rdrop-exit>
of the big end
<tp>
yep
<tp>
I'm a big endian kind of guy
<rdrop-exit>
Australians are by definition antipodal
<tp>
we dont understand big words like that, so we just say that we live at the 'arse end of the earth'
<rdrop-exit>
:)
<tp>
if a Australian were even to utter the word "antipodean", just the time ones mouth would be open would allow at least 3 flies to fly in!
<tp>
oh man, is my V2 of my diags program going to be cool!
<tp>
it's developed 'context sensitive' menues!
<rdrop-exit>
overkill R us
<tp>
I'll give them menues so 'fancy' they choke!
<rdrop-exit>
:))
<tp>
I think of it as 'necessary dumbing down for Arduino users'
<tp>
once the program has determined which MCU it is actually running on, the menu is refined to suit
<tp>
for instance, no point showing the "hidden 64kB Flash test" when there is no "hidden 64kB Flash" to test ?
<rdrop-exit>
grey it out
<tp>
they get confused enough as it is
<tp>
plus, what happens if their terminal has a black background ?
<rdrop-exit>
just change a bit on the color to get an adjacent color, or more than one bit to go further away from the original color
<rdrop-exit>
xor-ing a color with white gives you the most contrasted color from the original usually
<rdrop-exit>
: contrasting ( color -- color' ) white xor ;
<rdrop-exit>
changing less bits gets you closer on the color cube
<tp>
interesting!
<tp>
of course I have no idea what there terminal is from the CPU
<rdrop-exit>
at least that works with RGB colors
<tp>
as my menu runs on a MCU, not a pc
<rdrop-exit>
character-cell terminal codes use RGB
<tp>
it's too complex, I just use b&w
<tp>
I may offer a black OR white option later is anyone asks for it
<rdrop-exit>
if they change their default background color from black it probably inverts your text color as well, so you probably don't need to worry with b&w
<tp>
not here it doesnt!
<rdrop-exit>
no guarantee, express or implied ;)
<tp>
youve become far to MACanised!
<rdrop-exit>
Nah, this all old character-text terminal stuff from the 70s
<rdrop-exit>
* character-cell
<tp>
thats a HUGE error of logic to make!
<tp>
you have to bear in mind that the USA could put men on the Moon in 1969 but in 2019, Boeing cant even put a OSS resuply capsule in orbit at the right height
<rdrop-exit>
from a user-interface technology perspective I'm still stuck in the 70s, ^KS :)
<rdrop-exit>
^KY ^KC
<tp>
in other words, youre more advanced and can do more than technology today ?
smokeink has joined #forth
<tp>
Boeings excuses include "the dog ate our code printout", "the first stage booster and command capsule clocks had a sync problem"
<rdrop-exit>
reminds me of those coffee commercials
<tp>
I mean the USA got paid Boeing $4.8 BILLION and they get "sorry, the first stage booster and command capsule clocks had a sync problem, so it failed"
<tp>
-got
pierpal has joined #forth
<tp>
Then we get NASA saying 'the test was just a formality, we will send astronauts on the next flight anyway'
<tp>
like WTF ???
<rdrop-exit>
This is not your father's Space Program
<tp>
this is not the spacecraft youre looking for ...
<tp>
so true .. not even the one I watched live in Primary school in 1969 on a black and white TV
<rdrop-exit>
I watched at my grandmother's house, great memories
<tp>
space-x the privateer had to prove top NASA with a live test that their integrated capsule escape sytem works
<tp>
and they passsed 100%
<tp>
now NASA say that boeing is exempt from even proving they can get to orbit ???
<tp>
I recall in the shuttle days, the NASA accountants tried to get the independent shuttle 'code checking dept' shut down because the shuttle hadnt had any mission code errors
<tp>
hence it wasnt needed
<rdrop-exit>
wow
<tp>
NASA had set up the 'code writing' and 'code checking' departments as two separate entities, located far from each other. The employees were not allowed to even associate, no phone calls, no contact whatever
<tp>
that was my fathers NASA
<tp>
and obviously all code went thru the 'code checking' dept before approved for flight
<tp>
nowdays it's normal for a crew capsule to fail to make orbit and abort because 'of a clock sync issue between booster and capsule'
<rdrop-exit>
buried in self-imposed complexity
<tp>
some think that technology has actually regressed in many ways since the 60's
<tp>
yep, with increased complexity has come reduced reliability
<tp>
both in design and operation
<tp>
the biggest advantage of C is actually that it's 'standardised' so one can hire a programmer in Texas, or one in Bangladesh and get the same results
<tp>
it's all the same C, right ?
<rdrop-exit>
they probably abstracted the details away
<tp>
better yet, use Python because then the dual gramulators may be deployed to prevent framistan micro wobulations!
<tp>
this is totally independent of the encabulator rotational speed
<rdrop-exit>
they forgot to use finger trees
<tp>
LOL
<tp>
I'm giving you a 'finger tree' ;-)
<rdrop-exit>
:-))
<tp>
I just hope I'm facing the right direction
pierpal has quit [Ping timeout: 268 seconds]
<rdrop-exit>
nope
<tp>
ironically my C diagnostics program competitor seems to think a menu is in some way difficult in Forth, if only he knew ....
<tp>
the C solution (59 days later) is to jam a conclusion into a USB config string for the user to read via grepping the USB device and configuration descriptors
<rdrop-exit>
what's next? XML?
<rdrop-exit>
oops
<tp>
hahah, Ive done the XML part already, it's finished
<tp>
thats just a report containing the raw data for use with a database etc
<tp>
id paste it here but after you'd barfed all over your screen, you'd report me for spamming
Croran has quit [Ping timeout: 256 seconds]
<rdrop-exit>
damn right :)
<tp>
lol
<tp>
V2 is really simple, only 4 menu items because the Arduino users found it had too much stuff
<tp>
they just wanted the conclusion not the evidence or logic behind the conclusions
Croran has joined #forth
<tp>
I've been reminding myself continually since grade 6 ... "people don't care about how things work, they're not interested"
<rdrop-exit>
true
pierpal has joined #forth
xek_ has joined #forth
dys has joined #forth
actuallybatman has quit [Ping timeout: 260 seconds]
mtsd has joined #forth
APic has quit [Ping timeout: 265 seconds]
APic has joined #forth
rdrop-exit has quit [Quit: Lost terminal]
pierpal has quit [Quit: Poof]
pierpal has joined #forth
pierpal has quit [Read error: Connection reset by peer]
WickedShell has quit [Remote host closed the connection]
pierpal has joined #forth
pierpal has quit [Ping timeout: 265 seconds]
iyzsong has quit [Ping timeout: 240 seconds]
jsoft has quit [Ping timeout: 268 seconds]
dddddd has joined #forth
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` has joined #forth
X-Scale` is now known as X-Scale
pierpal has joined #forth
mtsd has quit [Quit: Leaving]
pierpal has quit [Read error: Connection reset by peer]
pierpal has joined #forth
pierpal has quit [Ping timeout: 260 seconds]
actuallybatman has joined #forth
cp- has quit [Quit: Disappeared in a puff of smoke]
cp- has joined #forth
pierpal has joined #forth
pierpal has quit [Ping timeout: 268 seconds]
dys has quit [Ping timeout: 245 seconds]
xek__ has joined #forth
xek_ has quit [Ping timeout: 260 seconds]
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
cartwright has quit [Ping timeout: 240 seconds]
cartwright has joined #forth
pierpal has joined #forth
pierpal has quit [Read error: Connection reset by peer]
smokeink has quit [Ping timeout: 265 seconds]
WickedShell has joined #forth
gravicappa has quit [Ping timeout: 268 seconds]
pierpal has joined #forth
dave0 has joined #forth
pierpal has quit [Quit: Poof]
pierpal has joined #forth
jedb_ has joined #forth
jedb has quit [Ping timeout: 260 seconds]
jedb__ has joined #forth
jedb_ has quit [Ping timeout: 240 seconds]
jedb_ has joined #forth
jedb__ has quit [Ping timeout: 265 seconds]
jedb_ has quit [Remote host closed the connection]