OpenEuphoria

1. inpout32

• Posted by andreasWagner 1 month ago
• 1532 views

Forked from Re: Mind blowingly impressive.

mem = open("/dev/mem", "rw") 
 
[snip] 
 

https://github.com/ellysh/InpOut32
https://www.highrez.co.uk/Downloads/InpOut32/

Maybe that will help. or is at least a starting point.
I have not tested it. I don't even have a computer with a 'real' serial or parallel port to test it on. And no interest in it either. From what I've seen it shouldn't be too difficult to write a wrapper for euphoria or phix.

Andreas

3. Re: inpout32

• Posted by jimcbrown (admin) 1 month ago
• 1534 views

And I am curious about you assuming that I'd ask you to be divulging every detail of your life and aspirations.

I simply stated that request because that knowledge helps me determine what might and might not be relevant or helpful to you. Naturally I respect your desire for privacy and do not require a response to every question asked or statement made - but also keep in mind that the less we (the community here) knows, the less effectively we are able to assist you.

With that in mind, I'll reiterate my request for clarification, so I can see how the Ultimate64 or a similar device can be made to work - or failing that what other alternative options may exist. Again though - will respect a non-response in the interests of your time and privacy - but hey, don't say that I didn't try to help!

Not at all, I'm not sure how one jumps from "couldn't find anything useful" to "prove .. have no knowledge". If anything, the opposite was true - I was asking for help from you to fill the information gap (so that I could in turn assist you better).

I mean sure, but I wonder if that's describing you mostly. Like in the above - really how did you make that jump in meaning?

Hmm, Good point - I didn't mean to imply that this would be the primary method, but I can see how a reasonable person might get that impression. Mostly I was just astonished at the irony (since Linux really does make it so so so easy to use that method).

Ah gotcha. So basically the ebay searches are of devices that are essentially USB flash sticks - except they connect via PATA rather than USB (so minus the USB part). I think I have an idea of what you meant now - to connect the PATA to the computer on one hand, but then to somehow modify the device so that it's able to connect and talk to what you're really interested in downstream and pass that along.

In a word, no. See below:

mem = open("/dev/mem", "rw") 

...why? It's pure Eu, no C, the only nixism is in one file name. And even that can be changed - would prefer a DOS-style open("MEM:") along the lines of the old open("COM1") and such?

I think "advanced" is the wrong term here. More like, Windoze locked things down to only the chosen few (C coding device driver developers) to protect the tide pod eaters.

I think the only accurate part of this is the term "male-dominated" ;)

Well obviously windoze is able to do it. I'm sure you've used a USB mouse and keyboard with windose, ergo windoze is able to do it.

See what I wrote above regarding USB keyboards and windoze;

Quote please?

Obviously you can - in fact you already suggested a method below. Just you were displeased with doing things via that method since it was slower than you would like.

I guess .. whatever works?

I can't disagree, but again ... whatever works I guess?

I can't think of a reason.

I guess, no requirement, therefore no complaint?

No.

No.

Not that I'm aware of.

If anything I'd suggest this would be superfluous to the point of actually reducing our helpfulness (as we'd have to weed through a lot of details to get to a good answer when a brief summary would have done so).

Mostly I just wanted to understand why a USB and ethernet supporting modernized Commodore64 clone couldn't do the job today, when the original Commodore64 was able to do it back in the 1980s.

Sadly I feel that you may be overestimating the tide-pod eaters of the 21st century.

Tide pod eaters. What can I say?

How? Why? The website and github clearly state it's for Windoze.

Speaking of which - the diversity of linux is beneficial to the ecosystem as a whole. Especially in terms of my employment (that is, keeping me employed). ;)

That's hilarious, as if Visual Studio and linux belong in the same paragraph.

The .NET and .VB are just examples, and C++ and Visual Studio compilers are just for development of the dll / driver itself.

Really you just need to know about DLL hell and how to wrap DLLs in OE (or Phix?).

Well, it's windoze. I can't blame you.

I double checked that - if you can install and use it, it seems just the open("/dev/mem") feature won't work beyond that limitation. But other ways to talk to parport io and et al seem like they should still work - such as DlPortReadPortUshort.

Yeah. Sadly it seems like the driver, while potentially a good solid choice in the past, has been unsupported since 2015.

Someone among those C coding device driver developers wrote some C code to make it happen on Windoze... what can I say? It's been long apparent that Windows should have been named Losedows because Windows isn't a WIN but a major LOSE!

5. Re: inpout32

• Posted by katsmeow 1 month ago
• 1276 views

And to be fair, i wrote a threaded httpd in mirc.
And an ftp uploader to a php webpage server, making dynamically created webpages here for serving from there.
And i built a cnc-able pcb driller, no way to connect it to OE.

So yea, i think i have pushed a lot of the limits of OE.
If i was coming across OE today, i'd pass it by.
There's just no way i can use OE to turn off the air conditioner.

Kat

7. Re: inpout32

• Posted by jmduro 1 month ago
• 1258 views

Even from Windows I can drive my pellet stove via the API of the micro-server. I could also drive any domotic device though an API.

Jean-Marc

9. Re: inpout32

• Posted by petelomax 1 month ago
• 1192 views

In fairness, though, afaict no-one has ever posted a demo of anything (remotely) similar on this forum or its predecessor or in the archives, in now 31 years.
Maybe something along the lines of oh dear, another pointless link. I suppose some part of it must be Euphoria/Phix, to justify it being here, but otherwise
it doesn't matter if it is on Windows, Linux, RasperryPI, Arduino, ESP8266, or whatever. That, btw, is the gauntlet being thrown down.

11. Re: inpout32

• Posted by petelomax 1 month ago
• 1146 views

Yep, 'cept now I suppose I really ought to go and find some cheap gadget to buy and have a play with...

I also forgot about WindowsSerialPortAccess and LinuxSerialCommunicationLibrary.

Can anyone think of a fun cheap little idea for me to try?

13. Re: inpout32

• Posted by jimcbrown (admin) 1 month ago
• 1075 views

I didn't. Consider another mind blown.

Really cool to see!

Wow, I didn't know github offered ARM64 support yet! Nice.

Really pleased to hear this. I'll keep my fingers crossed, please keep up the good work!

15. Re: inpout32

• Posted by petelomax 1 month ago
• 1035 views

I didn't look too hard, but I thought it was a "switch op do" statement - and wondered why the op parameter was declared object rather than integer(/enum).

17. Re: inpout32

• Posted by katsmeow 3 weeks ago
• 815 views

And i suppose the info Pete and Greg need to solve this is in the OE readme?

Kat

19. Re: inpout32

• Posted by jimcbrown (admin) 3 weeks ago
• 779 views

Nope, assuming https://github.com/OpenEuphoria/euphoria/blob/master/README.md is the one. But that's not surprising considering that Greg's the one who wrote it...

It almost sounds like it could have been a major lift just going through the lift, even assuming there was some trivial solution to the connection problem that was put into play.

In the interests of finding alternative solutions that don't require solving the below:

I mean, this is both the most controllable and uncontrollable element at the same time.

This is basically a solved problem. So to make it work, you just need to:

a) Learn C, and Windows Kernel Device Driver programming

or

b) Learn Unix

or

c) Integrate one of the modernized Commodore 64 solutions into the system to do the job

d) pay someone who knows a) or b) already to make something you can use. Note though that you'd probably get charged per line item, so this is the most difficult as well as the most expensive way to go.

It's a much older protocol that's not so used nowadays. I wanna say it was the mid-aughts that the transition happened. But now they're like DR-DOS - once general purpose, but now not in common use, mostly in specialized applications nowadays.

Agreed. As EU never had parport support in it's standard library (unless one counts the OS supporting opening it as a file or something like "LPT1:") it would indeed be quite the feat to accomplish this.

The problem with this is that both Windows Kernel and Unix devs tend to earn six figure salaries.

Well, not if one is using the right OS, but then again, see note about Unix dev salaries above.

I mean, we have a number of examples of that working, which you even quoted from. It's just - none of the ways work for you, and you're being a bit tight lipped about why.

Now of course that's your right - but think of it like a crossword puzzle. I have no idea what seven letter word T I A Y H C - plus a missing letter - should unscramble too, but if you give me the hint of "starts with CHA and ends with ITY" I could much more easily guess that the missing letter is R and the final word is CHARITY.

Going back to the above list of a, b, c, & d - d is obviously a non-starter for being too expensive, and a or b would be a tough pill to swallow (C or Unix?)

The reason why c got rejected remains unclear, which is unfortunate since with the limited view that you've shared on the matter, it's not clear how else to solve the puzzle here.

Well, of course not. If anyone could write Windows Kernel Device Drivers, we'd see a lot more of it. Also, the folks who do it wouldn't be making such high six figure salaries.

Ha! I wish there were 1000 different possibilities, instead of four. Much easier to find a winning combo this way.

Yeah, but this sort of misunderstanding is ripe for the picking when the entire ask is not fully spelled out.

Well, it can be done, but... see entire post above.

I mean, if the way forward is to program an Ultimate64 to monitor your water delivery and order water delivery from Walmart for you...

What was the excuse for not using an Ultimate64 again?

I did not know that.

I also did not know that. I'm surprised you are still getting assurances after a decade (as opposed to just silence or not being able to find anyone still connected to the project).

Not clear it would have helped anyways - at the time of the post at least, it only worked with FTDI USB UART devices if I'm understanding correctly. Though it sounds like you have more up to date information on this anyways.

That's the problem with the Windoze approach - each one seems to be using their own device drivers, and each time it's different. There's no one "generic" device driver that can talk to everything, rather you pick a product to talk to and then you hope a device driver exists to talk to that specific product over the type of GPIO that you want to use.

It's nice to be able to do it from a smart phone if you have one, but I totally get this being a non-starter if one doesn't have one.

How the heck does one drive a lawn mower with a single general purpose input output digital signal pin? Surely steering requires more than just on/off?

Well, no. It's in the name in fact - "general purpose"

But there are multiple types of GPIO. Parallel and RS232 Serial, and USB (actually each type like USB A, USB B, USB C is different), but others like FireWire too.

And talking to each type of GPIO is different and requires specific code for that. You can't really write one driver that talks on all GPIOs.

I think there's a typo, let me fix that for you.

I hope I got it right.

And you were given answers, but the problem is, there are no easy answers. You can pick from a), b), c), or d) - or maybe you can offer a few more details and we might be able to come up with a fifth option? Unlikely but...

mem = open("/dev/mem", "rw") 

For the sake of example, assuming that the computer is an older one with a PCI bus and you have PCI cards that hook into them and expose via hardware DMA.

Considering your expertise in hardware and tinkering - esp with getting connections to work with a C64 - I will presume that you know this step better than I, and what's needed here is just the (Eu) software piece.

The manufactor of the PCI cards should be able to tell you what address to use for DMA, but let's assume for this example it's 0x1304006c. And you need to read the first eight bytes from there.

include std/io.e 
mem = open("/dev/mem", "u") 
seek(mem, 319029356) 
sequence values = io:get_bytes(mem, 8) 

And now to write a command down at 0x1704006d

seek(mem, 386138221) 
puts(mem, new_values) 

21. Re: inpout32

• Posted by katsmeow 3 weeks ago
• 748 views

In the interest of debugging, breaking the post up, removing the caret over the 2nd 'e' in "Deschenes"....

I am interested in seeing how Pete uses the 2009 Jacques Deschenes serial.ew on a windows usb port. I was told it was impossible due to windows itself.

Kat

23. Re: inpout32

• Posted by jimcbrown (admin) 3 weeks ago
• 745 views

Same here.

The "it" part is a bit ambiguous. At least on the recent threads on this forum, no one said it was impossible to use his serial.ew - but if you know differently, a direct quote and a link would help.

What was mentioned regarding windows was this,

From https://openeuphoria.org/forum/m/138604.wc

Anyways, for serial.ew, I believe this is the relevant bit of code,

-- open a serial port and return the handle 
global function serial_open(integer com) 
atom fn_val, pComm 
   pComm = allocate_string(sprintf("\\\\.\\com%d",com)) 
   fn_val = c_func(iCreateFile,{pComm, 
                    GENERIC_READ+GENERIC_WRITE, 
                    0, 
                    0, 
                    OPEN_EXISTING, 
                    0, 
                    0 
                    }) 
   free(pComm) 
   return fn_val 
end function 

Basically, it opens COM1 or etc as a file. So if the windows USB port doesn't have a device driver that does COM1 then you're out of luck and it's impossible to use this...

And if I understand correctly that sata is never exposed as a COM port, then it'd never assist in speaking sata (since you mentioned it as an option, from https://openeuphoria.org/forum/m/138600.wc )

No, it's an actual and genuine question. After all, that was in response to:

If I'm confused about something regarding your meaning (which is quite likely) I at least hope you can understand why I am confused.

Ahh, that makes sense! I see how it'd be possible now. (More proof that it was a genuine question, considering the elaborate and detailed multi-part answer you gave!)

Actually, this is worth breaking down into multiple parts.

First, well I couldn't actually, because of the above confusion. (Sometimes it's possible to push through past some confusion, but one generally shouldn't take it as a given.)

Second, I'm not sure the problem is solvable at this point, as per my points on a)b)c)d) earlier in this thread. Getting a modernized Commodore 64 solution to interface with Windoze/OE was the last best hope...

Third, my understanding is because all serial.ew does is open a "COM" port, it won't do the job for you. If I'm mistaken about that, it's likely because I'm confused about what you're trying to accomplish and unable to get a sufficient level of clarification to become unconfused.

Finally, even if I could have been solving the problem - should I have? Perhaps the question that you answered was actually more interesting to me. Before asking for help, it's worth asking why other folks would offer to help - and what do they expect to get out of it.

25. Re: inpout32

• Posted by jimcbrown (admin) 3 weeks ago
• 707 views

Hmm, were you really?

We all knew already the same thing that Ryan learned the hard way. If it was easily doable (direct hardware access on modern Windoze), wouldn't have someone done it by now?

What's interesting is that it was doable on earlier M$ OSes - you've done it on DOS obviously, and the 9x line could have done it too. Even for 2k, the cygwin /dev/mem hack could have been reproduced. Even for XP or 2k3, you could have used that device driver that Andy suggested (without having to compile it yourself).

(So I missed something earlier. Aside from a)b)c)d) there is an option e) - using older MSDOS or even older Windoze for which the right freeware driver will give the desired results - but then this still doesn't work as another of your requirements is the ability to communicate with a modern system.)

So it's not just that it's so hard. Rather, as folks figure out how to achieve this specific goal (the one you are asking for), M$ goes ahead and closes what they consider a loophole. Hence irv was right when he made his point about this one specific OS.

Since you mentioned paying Ryan, let me see if I can help out by at least informing you about a reliable price.

I recall reading that today, it's at least $100k to make a Windoze device driver. However, most device drivers handle one small thing, while your concept is quite broader. That would otherwise be fine, but I imagine if a commercial company was handling the development of this driver for you, it would be treated as the equiv of - say - 15 regular drivers. So that'd be over a million dollars.

Well, of course we can. For this, I'd refer you to Greg's post here, https://openeuphoria.org/forum/m/138620.wc - he's doing it as time permits.

But of course Greg doesn't have a "Use Windoze" or "avoid C" restriction, so naturally this will be a nix solution, and I wouldn't be surprised at all if he ends up doing some C coding to fill in some missing glue or duct tape here and there.

It's not mine (it's from the serial.ew mentioned earlier) and serial.ew overall certainly does a bit more than that - but yes, that's why I had expressed concern that serial.ew might not do the job you need.

I think I understand what happened here.

You are describing the C64 Mini, which, according to https://www.c64-wiki.com/wiki/THEC64Mini

Of course that wouldn't work, hence why I did not suggest it.

But the actual Ultimate64 is ... not nix.

From https://www.c64-wiki.com/wiki/Ultimate_64

The wiki goes on to point out that it's port-level compatible and can be installed in the original computer case of the original C64. This despite that the Ultimte64 also provides things like ethernet and USB support.

Glad you finally gave an explanation - since it sounds like the c) option is back in the running!

I do recall you mentioning this actually. That said, we met on the OE mailing list, which I joined in the early aughts, so this would have taken place before we met.

Makes sense. Nix was harder to install and maintain back then - I do have experience and memories from those times as well. It sounds like the first ended up without enough swap to run everything, while the 2nd did not boot (some kind of LILO issue I guess - there were horror stories about non-standard BIOSes which played havoc with the LILO process).

Because you didn't understand it.

I think that would have been fine. Most likely Greg, Andy, and Pete would have given some help or pointers.

Hey, if you can give me a couple mil, perhaps then I can see what I can do?

27. Re: inpout32

• Posted by jimcbrown (admin) 3 weeks ago
• 701 views

Ah, so you took d) while Ryan took b).

I confess that this surprised me.

An even greater surprise. I can not recall this ever being discussed before. The closest would be https://openeuphoria.org/forum/m/138588.wc but there's no mention of Ryan or that this Pi was suppose to be able to operate the fan by design or of you reading the code for that Pi.

It is a good approach.

I'd argue that this proves that it is the problem. You can't do b) which is why you couldn't pierce the black box and fix the Pi to operate the fan.

So I don't know why Ryan didn't finish the job. Knowing that reason is important.

If Ryan simply retired, or say he rejoined the military, or became a religious missionary - then I'd say there's hope. If the code is Eu, then we on this forum can help out. Otherwise, we can find a dev who charges a reasonable price to look into the matter for you.

What we need to remember is that none of the folks here were as big in embedded I/O aas Ryan was. So if anyone could have made this work, it's Ryan.

If Ryan gave up because of technical difficulties, that suggests to me that it may not be possible. Of course, I'd need to speak to Ryan to get an idea of what difficulties he faced in that case - but the odds do not look good.

The other thing is that I feel like Ryan would have written the code in C. 'Nuff said there.

This is exactly why I pushed the Ultimate64 as the solution. With c) you have the same approach that Ryan took with the Pi - except that nix is not involved and you can write the code yourself on the 64. Meaning that you can maintain it yourself.

29. Re: inpout32

• Posted by jimcbrown (admin) 3 weeks ago
• 696 views

Ouch. Yeah, so as I wrote some months ago you'd have to settle for pre-ordering v2 and trying to stag v1 off of a reseller like ebay or something, unfortunately.

Ouch. I wonder if there's a third system that's being sold right now that would work...

Ouch. I guess that's a limit of an 8-bit CPU. It seems they support REUs to add more memory, though.

In any case, as you were able to deal with these limitations back in the 80s and still get it to work, I wouldn't be surprised to learn that this still ends up being better, with its warts and all. After all, we went to the moon with only 4kb.

I'd argue we still use them. Albeit they are stationary in coal and nuclear power plants, but they do the same job.

This is a line I'd love to see revived and modernized.

Yup.

I didn't understand this..

31. Re: inpout32

• Posted by jimcbrown (admin) 3 weeks ago
• 666 views

Ah, what I meant is that the REU mechanism (bank switching) appears to be the way to access the additional memory of the machine. Similar to how simulated expanded memory (EMS) to access extended memory (EMX) worked in DOS.

33. Re: inpout32

• Posted by katsmeow 2 weeks ago
• 576 views

https://zadig.akeo.ie/

https://en.wikipedia.org/wiki/WinUSB

Kat

35. Re: inpout32

• Posted by katsmeow 1 week ago
• 338 views

While that's a great goal, i am thinking a nice idea would be to use a win/nix/dos desktop/laptop as a main interface, to have graphics, bulk storage, data munging, internet access, and single point access to multiple sources. Surely a dumb remote can dump data upstream to a smarter terminal, Ryan at least got the dumb 3-pin serial device to talk to a Raspi, which displayed and logged and sorted and ran OE and was on the ethernet. I assumed, obviously incorrectly, the same raspi could have sensed switch closures and analog voltages (from light sensors, pressure sensors, etc)..

Starting a huge new project to run another 10 years to maybe put OE on a micro which doesn't have the megabytes to hold OE/OS/data, seems like drilling down too deeply, like using a microscope to buy car tires. And then the tires don't fit that car's rims, and the rims don't fit the car.

Kat

37. Re: inpout32

• Posted by ChrisB (moderator) 5 days ago
• 195 views

Hi

The FT232H is a USB to real world PC interface, not a microcontroller. Its current libraries are python, runs on a PC, easy enought to read and write a file onto the HD to communicate between python and EU. If you want standalone, then you will need to use a microcontroller, arduino/ESP32/PiZero/teensy etc etc, and you will need to program it. They are all experimentors boards, experiment, what have you got to lose. If you want a solution now, find a local hackers club and ask, donate some gear, and I'm sure someone will oblige.

Cheers

Chris

39. Re: inpout32

• Posted by petelomax 4 days ago
• 137 views

Looks pretty good to me, not that I've tried it yet. Just so you know, I've created a little PCAN entry for it: http://phix.x10.mx/pmwiki/pmwiki.php?n=Main.ArduLink

41. Re: inpout32

• Posted by katsmeow 2 days ago
• 81 views

Just tossing this out, for those in fear of orphaned hardware:

https://www.ebay.com/itm/364936877169

The virtual com port driver that's free is also not on the Silicon Labs website any more.