lng-devel — discussion of LNG development

[Lng-devel] english-spanish translation

[Virgilio R. C. <ad....@gm...>]

Dear LUnix team,
I'm a latinamerican user of libre software operating systems, I would
like to be volunteer for LUnix in order to translate your HTML
documents into my native language, spanish.

I would be very pleased because of my respect to your work as
low-level coders and *nix hackers.

Regards,
Virgilio

https://virgilioruilovacastillo.wordpress.com/

[Lng-devel] LUnix repository cloned on github

[Maciej W. <mwi...@gm...>]

Hi

For archival purposes I have been uploading my projects to github
since some time. Now there is a collection of "c64-", "geos-" and
"beos-" projects there:

https://github.com/ytmytm?tab=repositories

I have converted CVS root repository to git and it is now available on
github too, together with history of commits:

https://github.com/ytmytm/c64-lng

I don't mean to use this as a fork, maybe it will be just more
accessible than sourceforge services. I promise that if I ever receive
a git pull request, I will commit it to CVS too :).

ytm

Re: [Lng-devel] Anyone have LUnix 0.21 working with the "Virtual C64" emulator?

[Paul F. <pau...@gm...>]

Hi Daniel,

On 02. Feb, 2014, at 10:18, Daniel Dallmann <da...@gm...> wrote:
> I didn't meant to speak out a recommemdation to use Virtual C64. I wrongly blamed it to not implement character i/o correctly. But at least in that point the emulation seems to be complete. It is very basic and inferior to other emulators. In spite of that it can be used to check out LUnix.  :-)

ok, back to list topic, if there is one left over, that is...

I'd be happy if Lunix wasn't just dropped but made more like Unix, i.e. standarddized directories, "sh" should be able to handle paths, some sort if "vi", an assembler running under Lunix itself, etc.
-- 
cul8er

Paul
pau...@gm...

Re: [Lng-devel] Anyone have LUnix 0.21 working with the "Virtual C64" emulator?

[Daniel D. <da...@gm...>]

Hi Paul,

I didn't meant to speak out a recommemdation to use Virtual C64. I wrongly blamed it to not implement character i/o correctly. But at least in that point the emulation seems to be complete. It is very basic and inferior to other emulators. In spite of that it can be used to check out LUnix.  :-)

regards
  Daniel

> Am 01.02.2014 um 23:16 schrieb Paul Förster <pau...@gm...>:
> 
> Hi Daniel,
> 
>> On 01. Feb, 2014, at 13:09, Daniel Dallmann <da...@gm...> wrote:
>> I just tried Virtual C64 and it seems the emulation is not that bad after all.
> 
> I just gave it a try and I feel that it's by far inferior to for example Vice. One thing that immediately jumps at the user is that the screen is not wide enough. If you run stuff that uses the border, you might miss something.
> 
> Don't forget that it's a proof-of-concept or a case study for Professor Hoffmann and as such is probably incomplete and most likely stays that way. The fact that the last change was more than 18 months ago undermines this in my opinion. So I don't take this as s serious emulator. Still, for a POC or case study, it makes a good impression.
> 
> Yet, there's no way to attach a cart image. So advanced usage by attaching for example a Retro Replay or use a REU is a no-go. It's a plain vanilla C64, nothing more. If that's enough for you, then yes, this thing seems ok.
> 
> Still, I wonder why Professor Hoffmann didn't include the ROMs. There are no copyright issues, after all.
> -- 
> cul8er
> 
> Paul
> pau...@gm...
> 
> 
> 
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable 
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Lng-devel mailing list
> Lng...@li...
> https://lists.sourceforge.net/lists/listinfo/lng-devel

Re: [Lng-devel] Anyone have LUnix 0.21 working with the "Virtual C64" emulator?

[Paul F. <pau...@gm...>]

Hi Daniel,

On 01. Feb, 2014, at 13:09, Daniel Dallmann <da...@gm...> wrote:
> I just tried Virtual C64 and it seems the emulation is not that bad after all.

I just gave it a try and I feel that it's by far inferior to for example Vice. One thing that immediately jumps at the user is that the screen is not wide enough. If you run stuff that uses the border, you might miss something.

Don't forget that it's a proof-of-concept or a case study for Professor Hoffmann and as such is probably incomplete and most likely stays that way. The fact that the last change was more than 18 months ago undermines this in my opinion. So I don't take this as s serious emulator. Still, for a POC or case study, it makes a good impression.

Yet, there's no way to attach a cart image. So advanced usage by attaching for example a Retro Replay or use a REU is a no-go. It's a plain vanilla C64, nothing more. If that's enough for you, then yes, this thing seems ok.

Still, I wonder why Professor Hoffmann didn't include the ROMs. There are no copyright issues, after all.
-- 
cul8er

Paul
pau...@gm...

Re: [Lng-devel] Anyone have LUnix 0.21 working with the "Virtual C64" emulator?

[Daniel D. <da...@gm...>]

Hi,

Am 01.02.2014 um 12:01 schrieb Daniel Dallmann <da...@gm...>:
> Am 31.01.2014 um 17:10 schrieb Jacob Ritorto:
>> Emulator seems to come up OK, but when I
>> load "core.c64",8,1 and run it, it extracts LOADER ok but then seems  
>> to run forever in a rather tight loop trying to extract BOOT.
>> Is this piece supposed to run for several hours and I'm just giving  
>> up too soon?
> 
> I think Paul is right. I'd also guess, that it is a matter of the  
> quality of emulation.
> The *.c64 program tries to extract its content and to write to the  
> disc using Kernal calls for character I/O.
> Most probably the emulator only emulates the "load/save" functions  
> leaving the character I/O for simplicity.
> The extraction process should not take more than 1-2 minutes (on a  
> real C64). The VICE emulator does it in seconds.

I just tried Virtual C64 and it seems the emulation is not that bad after all.
The problem seems to be something different. If you attach to the file "packages.d64" and try to extract the files from the archive, the disc runs full and the process gets stuck. The "disc full" error it not handled correctly…

You should open the file "lunix.d64" instead. This disc image contains the already extracted files rather than the archives. Afterwards just load and run "loader", it worked for me.

best regards
  Daniel

Re: [Lng-devel] Anyone have LUnix 0.21 working with the "Virtual C64" emulator?

[Daniel D. <da...@gm...>]

Hi there!


Am 31.01.2014 um 17:10 schrieb Jacob Ritorto:
> Emulator seems to come up OK, but when I
> load "core.c64",8,1 and run it, it extracts LOADER ok but then seems  
> to run forever in a rather tight loop trying to extract BOOT.
> Is this piece supposed to run for several hours and I'm just giving  
> up too soon?

I think Paul is right. I'd also guess, that it is a matter of the  
quality of emulation.
The *.c64 program tries to extract its content and to write to the  
disc using Kernal calls for character I/O.
Most probably the emulator only emulates the "load/save" functions  
leaving the character I/O for simplicity.
The extraction process should not take more than 1-2 minutes (on a  
real C64). The VICE emulator does it in seconds.

best Regards
   Daniel

Re: [Lng-devel] Anyone have LUnix 0.21 working with the "Virtual C64" emulator?

[Paul F. <pau...@gm...>]

Hi Jacob,

who would have thought I'd ever read something again here... *LOL*

On 31. Jan, 2014, at 17:13, Jacob Ritorto <jri...@nu...> wrote:
Emulator seems to come up OK, but when I
> load "core.c64",8,1 and run it, it extracts LOADER ok but then seems to run forever in a rather tight loop trying to extract BOOT.
> Is this piece supposed to run for several hours and I'm just giving up too soon?

I looked at the Virtual C64 site. Hoffmann's decision to make complicated things easy does not suit a C64 and limit its use way too much. After all, a C64 is no Mac. Don't get me wrong, Macs are all over my house today and I love them, but you just can't make a C64 emulator much less option ridden than for example Vice is.

When Rosetta was still alive, I loved Power20 and Power64, option ridden too, but way more intuitive to use and cleaner interface. The guy who wrote them promised to make an Intel version for years now and still didn't. So I got back to Vice too. I don't like many of Vice's user interface decisions but it seems to be the best emulator on Mac right now.

I guess, your problem with having gotten stuck is due to Virtual C64's emulation being far from perfect (just a wild guess). Try Vice, or a real C64.
-- 
cul8er

Paul
pau...@gm...

[Lng-devel] Anyone have LUnix 0.21 working with the "Virtual C64" emulator?

[Jacob R. <jri...@nu...>]

Emulator seems to come up OK, but when I
load "core.c64",8,1 and run it, it extracts LOADER ok but then seems to run
forever in a rather tight loop trying to extract BOOT.
Is this piece supposed to run for several hours and I'm just giving up too
soon?

thx
jake

[Lng-devel] Anyone have LUnix 0.21 working with the "Virtual C64" emulator?

[Jacob R. <jac...@gm...>]

Emulator seems to come up OK, but when I
load "core.c64",8,1 and run it, it extracts LOADER ok but then seems to run
forever in a rather tight loop trying to extract BOOT.
Is this piece supposed to run for several hours and I'm just giving up too
soon?

thx
jake

Re: [Lng-devel] Lng-devel Digest, Vol 2, Issue 5

[Carsten S. <ca...@st...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

this is a collected answer, all on the same topic:

> 
> From: " Fran?ois Revol" <re...@fr...>
> Subject: Re: [Lng-devel] Lng-devel Digest, Vol 2, Issue 4
> 
>>> Atari 8bit is not using direct access to a FDC. Instead, the Ataris 
>>> have
>>> a serial BUS System called the SIO Bus. The Machine doesn't know what
>>> Hardware is in the Floppy (or Harddisk), its sending a command like
>>> "read sector x". The Atari SIO Bus is a historical forerunner to USB.
> 
> Hmm ok, so you'd probably have to implement a different driver, but you 
> could probably use the same module interface "fdc" I'm defining, with 
> functions like setdrive, settrack, readsector, ...
> Which would allow to implement a fat fs that works on both hardware.

A module fdc would be too low level. Atari SIO is similar to a SCSI
Driver on PC hardware. The command set is similar to the RBC (SCSI
Reduced Block Command set).

BTW, I'm working on FAT16/FAT32 driver for the Atari for our USB Drive
Project.


> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 6 Oct 2006 23:12:40 +0200
> From: "Maciej Witkowiak" <mwi...@gm...>
> Subject: Re: [Lng-devel] Lng-devel Digest, Vol 2, Issue 4
> To: lng...@li...
> Message-ID:
> 	<55f...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> 2006/10/6, Carsten Strotmann <ca...@st...>:
>>> The Atari Lunix Port has more problems that missing IO, it's only
>>> running in some emulators, not on real hardware, because it's disabling
>>> ROM and Interrupts, which is possible, but not the way Lunix Atari Port
>>> does it. The current port is a quick hack, and must probably redone from
>>> scratch with some more thought.
> 
> Strange, I thought that only 130XE was broken due to RAM expansion.
> Anyway, LNG was developed on emulator, but tested on my 65XE. I wrote
> it, but being of C= origin I don't know how to fix it.

I cannot speak for the whole Atari community, but I highly apprechiate
your work and I'm trying to do marketing for Lunix Atari 8bit port for a
couple of years now, explaining the idea and showing the current port. I
would interested joining the team, once the USB Project (SIO2USB,
microusb.org) is stable and working. This might be in Summer 2007.
Sorry, but I cannot promise anything and my workload is already very high.

> ------------------------------
> 
> Message: 4
> From: "TXG/MNX" <tx...@xs...>
> Subject: Re: [Lng-devel] Lng-devel Digest, Vol 2, Issue 4
> 
> Hello Carsten,
> 
> When I look at the subject I see something like LNG-devel Digist Vol 2,
> Issue 4 ??? Is this a special list you did a reply I got that one in the lng
> list I am member of but didn't see an orginal message with this subject...

I'm getting the list in Digest form (all postings from one day in  one
big E-Mail).

> ------------------------------
> 
> Message: 5
> Date: Sat, 7 Oct 2006 09:55:29 +0200
> From: "TXG/MNX" <tx...@xs...>
> Subject: [Lng-devel] diskdrives
> To: <lng...@li...>
> Message-ID: <011501c6e9e5$f631f6d0$4201a8c0@winxpe500>
> Content-Type: text/plain;	charset="us-ascii"
> 
> Hi,
> 
> I think the lunix kernel should call an fdc (disk) driver and thru this
> driver it can use a Filesystem driver.
> 
> The atari has different ways to work with diskdrives, harddisks so by
> designing a disk driver, people only need to change to the correct disk
> driver to use the rest this way most code would be universal and easy to
> port.
> 
> I would suggest that the disk driver should know the following commands
> 
> Read sector
> Get sector

Ok.

> Format Density 128/256 bytes dual/single sided

No. The RBC standard is a good template: http://www.t10.org/drafts.htm#rbc-

The commands are

* Format Unit - Format Media based on default or prior config
* Inquiry - get Information about Device / Drive / Media
* Mode Select - configure drive (density etc)
* Mode Sense - read configuration
* Read sector - read one sector, size defined by selected mode
* Read capacity - read overall media capacity (size)
* request sense - get status of last operation
* start/stop unit - start or stop unit
* synchronize cache - would be a noop on most 8bit platforms, but might
be interesting if the Block Driver is using additional RAM (Ramdisks)
for caching
* test unit ready - check if unit is responding to commands
* verify - reread and verify last written sector
* write sector - write one sector, size defined by selected mode

As for double/dual/single, there should be a "mode_select" call to
configure the drive.

> 
> The 8-bit doesn't need a DOS, most functions you describe are already inside
> a diskdrive.... But I always thought LUNIX could work without a DOS. 
> 

The Levels are:

FDC Driver -- programs the Floppy Controller
Block Driver -- Read/Write Sector
DOS -- Implements a Filesystem

As far as I know:
* the C64 has all 3 in the Floppy Drive.
* the Oric has all 3 in the Computer
* the Atari has FDC and Block Driver in the Floppy and DOS in the
Computer (loadable). The Atari is most similar to the PC Architecture,
where SCSI or ATA Drives have FDC Driver in Hardware, BlockDriver as
part of the BIOS/Firmware, and DOS is part of the Operating System
(MS-DOS, Windows, Linux ... )

> 
> Message: 10
> Date: Sat, 07 Oct 2006 17:50:30 +0200 CEST
> From: " Fran?ois Revol" <re...@fr...>
> Subject: Re: [Lng-devel] diskdrives
> To: tx...@xs..., lng...@li...
> Message-ID: <483856642-BeMail@laptop>
> Content-Type: text/plain; charset="windows-1252"
> 
>>> Hi,
>>>
>>> I think the lunix kernel should call an fdc (disk) driver and thru 
>>> this
>>> driver it can use a Filesystem driver.
> 
> Yes that's what I'm doing at the moment, like:
> #begindef FDC_struct8
>   .asc "fdc"
>   .byte 7
>   FDC_lock:     lda #0
>                  rts
>   FDC_unlock:   lda #0
>                  rts
>   FDC_setdrive:         jmp lkf_suicide ; set current drive (0-3)
>   FDC_sectorsize:       jmp lkf_suicide ; return block size (in pages)
>   FDC_sectorbuffer:     jmp lkf_suicide ; return block buffer page 
> number
>   FDC_settrack:         jmp lkf_suicide ; set current track
>   FDC_readsector:       jmp lkf_suicide ;
>   FDC_writesector:      jmp lkf_suicide
> #enddef
> 
> It's not fixed yet, just a try, it will need other stuff like 
> getgeometry, eventually format, but that's not strictly needed to read/
> write disks.
> 
> Fran?ois.

As Lunix is a "kind" of "Unix", taking a look on the implementation of
old and current Unix Systems is helpful, esp. on the IO Subsystem. IMHO
there should be 3 level as discussed above:

1) Floppy / Harddrive / USB Controller Driver
2) Block Driver (kind of SCSI RBC)
3) Filesystem Driver (FAT, Atari 2.x FMS, Apple II DOS/ProDOS, C64 DOS, ...)

Surely if the FDC Driver level already contains a "read_sector" command,
the Block Driver call for "read_sector" will go directly linked into the
 FDC Driver. But to be able to include other drives like USB in Lunix, a
three Level System would be ideal.

Best regards

Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFJ9obiDbv+TR5q6IRAi3ZAKCM6+Luj6cejoDjdZdq4pFfJdSFwQCfTZyn
qdBNVVYHQn8u7rNst5SSLSc=
=qdDO
-----END PGP SIGNATURE-----

Re: [Lng-devel] Atari port

[Maciej W. <mwi...@gm...>]

2006/10/7, TXG/MNX <tx...@xs...>:
> > As for disk I/O, C64 and its disk drives (also 64net/2
> > driver) work on higher level than read/write sector, so does
> > LNG. You would have to write DOS part: everything from
> > read/write sector to the level of open file, close file,
> > read/write byte/block from stream, show/make/remove/change directory.
> The 8-bit doesn't need a DOS, most functions you describe are already inside
> a diskdrive.... But I always thought LUNIX could work without a DOS.

This is misunderstanding of "DOS" term. On C64 disk drive is a device
with its own CPU, RAM and ROM with DOS that handles lowlevel stuff.
C64 merely send commands, receives status, opens a file and
reads/writes data stream.

>From what I know Atari drives are devices that can only r/w a sector
and all the stuff like block allocation map, directory handling, file
entry creation, file deleting etc. is handled by a piece of software
loaded to computer - DOS. This part would have to be written from
scratch for architectures that support only block sector access to
data storage.

Anyway, if anyone wants to do something useful I encourage to write fs
module with ramdisk (or read-only version for prepared images). This
is something that would give huge benefits with little work.

ytm

Re: [Lng-devel] Atari port

[TXG/MNX <tx...@xs...>]

Hi, 

> Maciej Witkowiak
> Sent: zaterdag 7 oktober 2006 10:36
> To: lng...@li...
> Subject: Re: [Lng-devel] Atari port
> 
> 2006/10/7, TXG/MNX <tx...@xs...>:
> > Hi,
> >
> > The atari port needs to be re-done for sure but I think more things 
> > would be documented to make it better multi-platform.
> 
> Probably Atari needs to be done, but I won't do it. I wrote 
> it in about a week or so without any previous knowledge about 
> Atari system.
> I have announced it to the Atari community, received some 
> comments and that's it. If Atari users don't care about LNG, 
> there will never be a proper port. A quick way to make Atari 
> port more usable is to write ramdisk filesystem and bundle 
> some of the apps on it with kernel image.

I agree a ramdisk would be good to use, when lunix will be loaded in the
normal 64Kb a ramdisk for the expanded machines..
My Atari XE machines do have 1Mb extra expanded memory... Ramdisk also are
fast...
 
> > On the c64 the port works, how does this machine handle it 
> to run with 
> > the OS and interupts stopped? Or how does this work on the 
> ORIC systems.
> > All these systems use the 6502 so we need to find the hardware 
> > differences and make that part separate from the kernel I think.
> 
> I think you should see the source code before asking those questions.
> Only ROM is turned off, the interrupts from timer are 
> enabled. Pretty much all kernel stuff is already divided into 
> architectures - initial setup, reset, keyboard, console and 
> serial drivers, etc.

I did know some of this... I thought the OS and Interupts did stop on the
8-bit... Atleast that seems to be one of the things it did crash... Need to
rewrite the stuff... The console/screen handling is the biggest part to
(re-)write on the 8-bit...

> As for disk I/O, C64 and its disk drives (also 64net/2 
> driver) work on higher level than read/write sector, so does 
> LNG. You would have to write DOS part: everything from 
> read/write sector to the level of open file, close file, 
> read/write byte/block from stream, show/make/remove/change directory.
> 
> ytm

The 8-bit doesn't need a DOS, most functions you describe are already inside
a diskdrive.... But I always thought LUNIX could work without a DOS. 

TXG/MNX

Re: [Lng-devel] Atari port

[Maciej W. <mwi...@gm...>]

2006/10/7, TXG/MNX <tx...@xs...>:
> Hi,
>
> The atari port needs to be re-done for sure but I think more things would be
> documented to make it better multi-platform.

Probably Atari needs to be done, but I won't do it. I wrote it in
about a week or so without any previous knowledge about Atari system.
I have announced it to the Atari community, received some comments and
that's it. If Atari users don't care about LNG, there will never be a
proper port. A quick way to make Atari port more usable is to write
ramdisk filesystem and bundle some of the apps on it with kernel
image.

> On the c64 the port works, how does this machine handle it to run with the
> OS and interupts stopped? Or how does this work on the ORIC systems.
> All these systems use the 6502 so we need to find the hardware differences
> and make that part separate from the kernel I think.

I think you should see the source code before asking those questions.
Only ROM is turned off, the interrupts from timer are enabled. Pretty
much all kernel stuff is already divided into architectures - initial
setup, reset, keyboard, console and serial drivers, etc.

As for disk I/O, C64 and its disk drives (also 64net/2 driver) work on
higher level than read/write sector, so does LNG. You would have to
write DOS part: everything from read/write sector to the level of open
file, close file, read/write byte/block from stream,
show/make/remove/change directory.

ytm

[Lng-devel] Atari port

[TXG/MNX <tx...@xs...>]

Hi,

The atari port needs to be re-done for sure but I think more things would be
documented to make it better multi-platform.

On the c64 the port works, how does this machine handle it to run with the
OS and interupts stopped? Or how does this work on the ORIC systems.
All these systems use the 6502 so we need to find the hardware differences
and make that part separate from the kernel I think.

TXG/MNX

[Lng-devel] diskdrives

[TXG/MNX <tx...@xs...>]

Hi,

I think the lunix kernel should call an fdc (disk) driver and thru this
driver it can use a Filesystem driver.

The atari has different ways to work with diskdrives, harddisks so by
designing a disk driver, people only need to change to the correct disk
driver to use the rest this way most code would be universal and easy to
port.

I would suggest that the disk driver should know the following commands

Read sector
Get sector
Format Density 128/256 bytes dual/single sided

The atari drive already does do a conversion of track/side selection when
selecting a sector nr. So maybe for ORIC systems this can be done inside de
disk driver.

I think read/write a sector would be enough, this would be easy to implement
on any platform I think.

TXG/MNX

Re: [Lng-devel] Lng-devel Digest, Vol 2, Issue 4

[TXG/MNX <tx...@xs...>]

Hello Carsten,

When I look at the subject I see something like LNG-devel Digist Vol 2,
Issue 4 ??? Is this a special list you did a reply I got that one in the lng
list I am member of but didn't see an orginal message with this subject...

TXG/MNX

Re: [Lng-devel] Lng-devel Digest, Vol 2, Issue 4

[Maciej W. <mwi...@gm...>]

2006/10/6, Carsten Strotmann <ca...@st...>:
> The Atari Lunix Port has more problems that missing IO, it's only
> running in some emulators, not on real hardware, because it's disabling
> ROM and Interrupts, which is possible, but not the way Lunix Atari Port
> does it. The current port is a quick hack, and must probably redone from
> scratch with some more thought.

Strange, I thought that only 130XE was broken due to RAM expansion.
Anyway, LNG was developed on emulator, but tested on my 65XE. I wrote
it, but being of C= origin I don't know how to fix it.

ytm

Re: [Lng-devel] Lng-devel Digest, Vol 2, Issue 4

[Carsten S. <ca...@st...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> From: " Fran?ois Revol" <re...@fr...>
> I'm writing a driver for the 2 different oric disc drives which use a 
> WDC 179x/177x chip, if the atari has a similar FDC it should probably 
> be easy to adapt the code. I'll have to separate WDC-related parts from 
> the glue stuff (disk and side select for ex) anyway as they are 
> different between drives.
> 
> Fran?ois.


Atari 8bit is not using direct access to a FDC. Instead, the Ataris have
a serial BUS System called the SIO Bus. The Machine doesn't know what
Hardware is in the Floppy (or Harddisk), its sending a command like
"read sector x". The Atari SIO Bus is a historical forerunner to USB.

The Atari Lunix Port has more problems that missing IO, it's only
running in some emulators, not on real hardware, because it's disabling
ROM and Interrupts, which is possible, but not the way Lunix Atari Port
does it. The current port is a quick hack, and must probably redone from
scratch with some more thought.

Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFJq/9iDbv+TR5q6IRAnURAJ9hPxOFq+7FMGxQftoKk9LeDd1o1QCgoxaC
9s+s2nYwjn89a0oCT8nquXo=
=0MZy
-----END PGP SIGNATURE-----

[Lng-devel] Odp: LUNIX NG

[Maciej W. <mwi...@gm...>]

2006/10/2, TXG/MNX <tx...@xs...>:
>
> It's cool to see the list is still active ;-)
>
> I would like to see an Atari 8-bit port ... And a universal LUNIX
> filesystem...

Well, there _is_ Atari 8-bit port, it's just not that useful without
disk I/O. As for universal LUNIX filesystem, I think that all
architectures would benefit from ramdisk or something like Linux
initrd mechanism.

ytm

[Lng-devel] LUNIX NG

[TXG/MNX <tx...@xs...>]

It's cool to see the list is still active ;-)

I would like to see an Atari 8-bit port ... And a universal LUNIX
filesystem...

Re: [Lng-devel] LUnix NG port to ORIC Atmos

[Daniel G. <da...@ho...>]

On Wed, 27 Sep 2006 03:20:00 -0400
"Greg King" <gn...@er...> wrote:

> From: Maciej Witkowiak; on Saturday, September 23, 2006; at 07:58 AM
> -0400
> >
> > It seems that you will also have to correct uname tool to display
> > new architecture message.
>=20
> I think that the "larchf_type" mask should be expanded to three bits;
> we should have eight architecture slots (just in case someone
> eventually does want to develop the other ports that have been
> mentioned in the past [Apple and BBC]).
>=20
> From: Fran=E7ois Revol; on Sunday, September 24, 2006; at 10:12 PM -0400
> >
> > How many ppl are still reading this list, btw? :)
> > Is anyone still working on Apple or Atari port?
> > I might be able to get my hands on an Apple II, but I probably won't
> > have the time to touch it.
>=20
> Obviously, at least two people still read this list -- and respond to
> messages.
> And, we haven't abandoned the development of more LUnix code [but,
> I'm not ambitious enough to try to write an NFS driver :-) ].

I'm reading the list too even though I hardly code anything at all
these days.. stoked to see the cool stuff you guys do. Keep up!

	cheers ./daniel
--=20
daniel dege gustafson :: daniel at hobbit dot se :: www.rastplats.se
:: "Time is an illusion. Lunchtime doubly so" -- Douglas N. Adams ::

Re: [Lng-devel] LUnix NG port to ORIC Atmos

[Adam P. <ad...@ad...>]

Me too. I was a couple of years ago working on a BBC port which has been=20
sitting stale for a while.


On Wed, 27 Sep 2006 10:15, Brendan Burns wrote:
> I'll just chime in a "me too" and I'm interested in working on a port
> to Apple II, when I have time. (which is a long time in the future...)
>
> --brendan
> On Sep 27, 2006, at 8:17 AM, Jos=E9 M. Morales F. wrote:
>
>>  Fierman wrote:
>>>
>>>  On Wed, 27 Sep 2006, Greg King wrote:
>>>
>>>>>  How many ppl are still reading this list, btw? :)
>>>>>  Is anyone still working on Apple or Atari port?
>>>>>  I might be able to get my hands on an Apple II, but I probably
>>>>>  won't
>>>>>  have the time to touch it.
>>>>
>>>>  Obviously, at least two people still read this list -- and
>>>>  respond to
>>>>  messages.
>>>>  And, we haven't abandoned the development of more LUnix code
>>>>  [but, I'm not
>>>>  ambitious enough to try to write an NFS driver :-) ].
>>>
>>>
>>>  most interested still, and reading. not participating in development
>>>  though, not likely to do so anytime soon :)
>>>  just wanted to say 'thanks' and let you know that there _are_
>>>  interested
>>>  people around.
>>>
>>>  fierman
>>
>>  	Exactly the same for me...	=A1=A1=A1 Just keep it going !!!
>>
>>
>>  ----------------------------------------------------------------------
>>  ---
>>  Take Surveys. Earn Cash. Influence the Future of IT
>>  Join SourceForge.net's Techsay panel and you'll get the chance to
>>  share your
>>  opinions on IT & business topics through brief surveys -- and earn
>>  cash
>>  http://www.techsay.com/default.php?
>>  page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
>>  _______________________________________________
>>  Lng-devel mailing list
>>  Lng...@li...
>>  https://lists.sourceforge.net/lists/listinfo/lng-devel
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share=
=20
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Lng-devel mailing list
> Lng...@li...
> https://lists.sourceforge.net/lists/listinfo/lng-devel=

Re: [Lng-devel] LUnix NG port to ORIC Atmos

[Brendan B. <bb...@cs...>]

I'll just chime in a "me too" and I'm interested in working on a port =20=

to Apple II, when I have time. (which is a long time in the future...)

--brendan
On Sep 27, 2006, at 8:17 AM, Jos=E9 M. Morales F. wrote:

> Fierman wrote:
>>
>> On Wed, 27 Sep 2006, Greg King wrote:
>>
>>>> How many ppl are still reading this list, btw? :)
>>>> Is anyone still working on Apple or Atari port?
>>>> I might be able to get my hands on an Apple II, but I probably =20
>>>> won't
>>>> have the time to touch it.
>>>
>>> Obviously, at least two people still read this list -- and =20
>>> respond to
>>> messages.
>>> And, we haven't abandoned the development of more LUnix code =20
>>> [but, I'm not
>>> ambitious enough to try to write an NFS driver :-) ].
>>
>>
>> most interested still, and reading. not participating in development
>> though, not likely to do so anytime soon :)
>> just wanted to say 'thanks' and let you know that there _are_ =20
>> interested
>> people around.
>>
>> fierman
>
> 	Exactly the same for me...	=A1=A1=A1 Just keep it going !!!
>
>
> ----------------------------------------------------------------------=20=

> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys -- and earn =20
> cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Lng-devel mailing list
> Lng...@li...
> https://lists.sourceforge.net/lists/listinfo/lng-devel

Re: [Lng-devel] LUnix NG port to ORIC Atmos

[<jm...@ma...>]

Fierman wrote:
>=20
> On Wed, 27 Sep 2006, Greg King wrote:
>=20
>>>How many ppl are still reading this list, btw? :)
>>>Is anyone still working on Apple or Atari port?
>>>I might be able to get my hands on an Apple II, but I probably won't
>>>have the time to touch it.
>>
>>Obviously, at least two people still read this list -- and respond to
>>messages.
>>And, we haven't abandoned the development of more LUnix code [but, I'm =
not
>>ambitious enough to try to write an NFS driver :-) ].
>=20
>=20
> most interested still, and reading. not participating in development
> though, not likely to do so anytime soon :)
> just wanted to say 'thanks' and let you know that there _are_ intereste=
d
> people around.
>=20
> fierman

	Exactly the same for me...	=A1=A1=A1 Just keep it going !!!